/irc-logs / w3c / #webapps / 2009-05-05 / end
Options:
- # Session Start: Tue May 05 00:00:00 2009
- # Session Ident: #webapps
- # [00:46] * tlr is now known as tlr-off
- # [00:48] * Quits: arve (arve@84.202.133.45) (Connection reset by peer)
- # [00:49] * Joins: arve (arve@84.202.133.45)
- # [00:56] * Quits: arve (arve@84.202.133.45) (Quit: Ex-Chat)
- # [01:14] * Quits: taf2 (taf2@38.99.201.242) (Quit: taf2)
- # [01:27] * Quits: heycam (cam@203.217.72.53) (Quit: bye)
- # [02:11] * Joins: taf2 (taf2@68.49.245.59)
- # [02:24] * Quits: tlr-off (tlr@128.30.52.30) (Quit: tlr-off)
- # [02:31] * Joins: heycam (cam@130.194.73.110)
- # [03:33] * Quits: heycam (cam@130.194.73.110) (Quit: bye)
- # [03:53] * Quits: taf2 (taf2@68.49.245.59) (Quit: taf2)
- # [04:14] * Quits: annevk (opera@83.86.138.148) (Quit: annevk)
- # [04:42] * Quits: phenny (phenny@80.68.92.65) (Ping timeout)
- # [05:16] * Quits: aroben (aroben@71.58.77.15) (Ping timeout)
- # [05:31] * Joins: aroben (aroben@71.58.77.15)
- # [05:55] * Joins: heycam (cam@130.194.73.110)
- # [08:21] * Quits: aroben (aroben@71.58.77.15) (Connection reset by peer)
- # [08:34] * Quits: heycam (cam@130.194.73.110) (Quit: bye)
- # [09:05] * Joins: heycam (cam@203.217.72.53)
- # [09:09] * Joins: darobin (darobin@85.169.117.248)
- # [09:42] * Quits: darobin (darobin@85.169.117.248) (Quit: darobin)
- # [10:06] * Joins: Marcos_ (Marcos@213.236.208.22)
- # [10:32] * Joins: darobin (darobin@88.162.131.13)
- # [10:49] * Joins: annevk (opera@83.86.138.148)
- # [11:45] * Quits: darobin (darobin@88.162.131.13) (Quit: darobin)
- # [11:51] * Quits: smaug (chatzilla@82.181.140.15) (Ping timeout)
- # [11:53] * Joins: smaug (chatzilla@82.181.136.64)
- # [11:55] * Quits: Lachy (Lachlan@85.196.122.246) (Quit: This computer has gone to sleep)
- # [12:01] * Joins: ArtB (d0309a43@128.30.52.43)
- # [12:08] * Quits: smaug (chatzilla@82.181.136.64) (Quit: ChatZilla 0.9.84-2008121723 [Firefox 3.6a1pre/20090424134942])
- # [12:09] * Joins: smaug (chatzilla@82.181.136.64)
- # [12:09] * Joins: Lachy (Lachlan@213.236.208.22)
- # [12:10] * Joins: darobin (darobin@88.162.131.13)
- # [12:31] <ArtB> hendry, yt?
- # [12:34] * Quits: smaug (chatzilla@82.181.136.64) (Ping timeout)
- # [12:36] <hendry> ArtB: yes
- # [12:37] <ArtB> just sent you an email re dsp:Identifier
- # [12:37] <hendry> ArtB: on the thread or?
- # [12:38] <hendry> ArtB: ok, now i see it
- # [12:38] <hendry> more than a UA spec ..hey
- # [12:44] <hendry> oh i see Marcos's mail now
- # [12:44] <hendry> which is good
- # [12:44] <hendry> there is also that unique-ness question
- # [12:45] <hendry> i'm still not comfortable with it
- # [12:45] <hendry> but i'm no CA expert
- # [12:45] <ArtB> "it" is Frederick's proposal?
- # [12:46] <ArtB> I thought your question was more about whether or not the UA is supposed do anything with this property
- # [12:46] * Marcos_ is now known as marcos
- # [12:46] * marcos waves
- # [12:47] <hendry> ok, sticking to the point
- # [12:48] * hendry missed breakfast and is only 15mins away from lunch... oh gosh
- # [12:48] <hendry> well i won't care really. so if ppl are happy it's more than a UA spec then fine.
- # [12:49] <marcos> yeah, I can live with that too
- # [12:50] <ArtB> I would expect the XML Sig Props spec to address the uniqueness requirement
- # [12:51] <ArtB> hendry, since this spec is now in Last Call, we need to round-trip all comments with the Commentor to see if our proposed solution to a comment is OK or not
- # [12:52] <ArtB> so if you can live with FH's proposal, please do respond as such; if you cannot live with that proposal, please explain why
- # [12:52] <hendry> ok, i'll reply on the thread quickly now then
- # [12:58] * Joins: smaug (chatzilla@82.181.140.15)
- # [13:01] <hendry> lunch time :)
- # [13:02] <ArtB> thanks hendry!
- # [13:03] * ArtB moves ~10 related emails from Inbox to Widgets folders :-)
- # [13:04] <marcos> artb, took you advice to fold the i18n stuff straight into the spec and not produce yet another doc
- # [13:15] <ArtB> ok Marcos
- # [13:15] <ArtB> have you finished that task?
- # [13:16] <marcos> no, it's a big job
- # [13:16] <marcos> I think I said thursday
- # [13:16] <marcos> in the last teleconf
- # [13:17] <ArtB> yes, that's what I recall too
- # [13:17] <marcos> I'm hopeful to be done with the integration by then
- # [13:47] * Joins: taf2 (taf2@38.99.201.242)
- # [13:49] <marcos> ArtB: how does this sound "An implementation detail is some functional aspect that is beyond the scope of this specification and left to be implemented at the discretion of the implementer."
- # [13:49] <marcos> ?
- # [13:50] <anne> why do you need to define what an implementation detail is?
- # [13:51] <marcos> here we go...Because there are a few things that are left explicitly as an implementation detail (e.g., how to derive the user agent's locale)
- # [13:51] <anne> that doesn't sound like an implementation detail
- # [13:51] <anne> that sounds like you leave things undefined
- # [13:51] <marcos> no
- # [13:51] <anne> an implementation detail is whether to allocate 5 or 10 megabyte of memory
- # [13:52] <anne> or some such
- # [13:52] <marcos> "The user agent's locale is the end-user's preferred language and regional settings derived from the operating system or user agent (e.g. English, Australia). As there are numerous ways a user agent can acquire the end-user's language preference, how the user agent's locale is derived is an implementation detail."
- # [13:52] <marcos> however... "Within a user agent, this is represented by zero or more language tags and placed in the ua-language list."
- # [13:53] <marcos> so, we don't care how you get the UA's locale, just that you put it into a list
- # [13:54] <marcos> For instance, the end-user may have specified a language preference at install time by selecting a preferred language, or languages from a list, or a list of preferred languages could have been derived from the OS, etc.
- # [13:54] <marcos> anne, make sense?
- # [13:55] * ArtB catches up
- # [13:58] <anne> HTML5 simply has "may use the user's preferred language settings"
- # [13:58] <anne> for a similar situation
- # [14:01] * Joins: tlr (tlr@128.30.52.30)
- # [14:01] <marcos> anne, we are just a little more descriptive. I'm finding HTML5 a little too abstract in places.
- # [14:02] * marcos just thinks it's because he is not so smart, but it helps me to be clear.
- # [14:02] <marcos> :)
- # [14:02] <anne> i'm still not quite convinced it's an implementation detail
- # [14:02] <anne> it's more like it's left up to the implementation
- # [14:02] <marcos> what's the dif?
- # [14:03] <anne> an implementation detail is something that does not matter to interoperability under normal circumstances
- # [14:03] <marcos> right, that's what I want
- # [14:03] <anne> but it's not the case here :)
- # [14:04] <anne> the "etc." indicates that implementations can choose different strategies
- # [14:04] <anne> and end up with different results
- # [14:04] <anne> under normal circumstances
- # [14:04] <marcos> right
- # [14:04] <anne> so it's not an implementation detail
- # [14:04] <marcos> ok, I'm getting you
- # [14:06] * ArtB thinks this discussion underscores the low probability of us successfully meeting our Ease of Authoring design goal with the proposed L10N model ...
- # [14:06] <marcos> I don't agree. The i18n model is a no brainer.
- # [14:06] <ArtB> It's not an I18N model! :-)
- # [14:07] <marcos> hehe
- # [14:08] <marcos> The element-based localization model is simple
- # [14:08] <marcos> the folder-based localization model is also simple
- # [14:08] <marcos> but can get complex if an author tries to get fancy pants with it
- # [14:09] <marcos> otherwise, it's not more complicated then what is already used by widget engines
- # [14:10] <marcos> ACTION-298
- # [14:10] <marcos> can prolly be closed
- # [14:11] <anne> btw, if HTML5 is too abstract, what is HTML4?
- # [14:12] <marcos> hehe
- # [14:12] <ArtB> marcos, yes agree on 298. But what about 299? I don't think your proposal addressed this: http://www.w3.org/2008/webapps/track/actions/299
- # [14:12] <marcos> I don't remember what that was about
- # [14:13] <marcos> It was i18n core that suggested we use ISO-8859-1
- # [14:13] <marcos> That is what is in the spec, so as far as I'm concerned that is closed
- # [14:13] <anne> iso-8859-1 does not exist on the Web
- # [14:14] <ArtB> I thought there was a question about if it should be UTF-8
- # [14:14] <anne> it's just an alias for windows-1252
- # [14:14] <ArtB> but I'm not positive and don't have a pointer handy ...
- # [14:14] <marcos> ok, so we should just default to windows-1252?
- # [14:15] <ArtB> perhaps we should seek advice from i18n WG
- # [14:16] <marcos> The proposal is: when <content src="index.html"/> is used, and you cannot derive the encoding of index.html, you should use ISO-8859-1.
- # [14:16] <marcos> Artb, it was i18n core that told us to do that
- # [14:16] <marcos> we had UTF-8 originally
- # [14:17] <ArtB> hmmm
- # [14:17] <marcos> ok, now it makes sense
- # [14:17] <marcos> should that be a "Should/Must/May" that that happens
- # [14:18] <anne> must be UTF-8 I'd say
- # [14:18] <ArtB> +1
- # [14:19] <ArtB> marcos, which section of P&C is relevant here?
- # [14:19] <marcos> The way it works in the spec is: firstly assume ISO-8859-1, if encoding sniffing fails, use ISO-8859-1... I agree. I had UTF-8 originally, I'll change it back
- # [14:19] * marcos searches...
- # [14:19] <marcos> step 3..
- # [14:19] <marcos> Configuration Defaults
- # [14:19] <marcos> start file encoding
- # [14:19] <marcos> DOMString
- # [14:19] <marcos> ISO-8859-1
- # [14:19] <marcos> Step 7
- # [14:20] <marcos> The character encoding of the start file, corresponding to the content element's charset attribute.
- # [14:20] <anne> <content> has a charset attribute?
- # [14:20] <marcos> yes, but I think we might dump it
- # [14:20] <marcos> (again, at the request of i18n)
- # [14:20] <marcos> they asked us to include it
- # [14:21] <marcos> Might dump it in favor of content-type="some/type;charset=foobar"
- # [14:21] <marcos> s/content-type="/type="
- # [14:22] <marcos> so <content type="text/html;charset=UTF-8" src="my.php" />
- # [14:24] <marcos> it kills one attribute
- # [14:24] <marcos> which is good
- # [14:24] <anne> it makes the other more complex
- # [14:24] <marcos> sure
- # [14:24] <anne> not entirely convinced you need either, but oh well
- # [14:25] <marcos> ok, what do you do when you get <content src="xmy"/>, where xmy is SilverLight?
- # [14:26] <marcos> just sniff?
- # [14:27] * Quits: anne (annevk@83.86.138.148) (Ping timeout)
- # [14:28] * Quits: annevk (opera@83.86.138.148) (Ping timeout)
- # [15:02] * Joins: anne (annevk@94.210.210.44)
- # [15:10] * Joins: arve (arve@85.89.230.140)
- # [15:10] * Quits: anne (annevk@94.210.210.44) (Ping timeout)
- # [15:14] * Quits: arve (arve@85.89.230.140) (Ping timeout)
- # [15:27] * Joins: anne (annevk@94.210.210.44)
- # [15:35] <hendry> marcos: http://dev.w3.org/2006/waf/widgets/#the-preference-element
- # [15:35] <hendry> marcos: is it mandatory?
- # [15:39] <hendry> for a widget runtime.
- # [16:16] <marcos> hendry: what?
- # [16:16] * Joins: arve (arve@85.89.230.140)
- # [16:16] <marcos> no, not mendatory
- # [16:17] <marcos> Arve, where you at?
- # [16:22] <hendry> marcos: is there a JS API to get/set preferences to along with it?
- # [16:23] <marcos> yes
- # [16:23] <marcos> widget.preferences implements Storage
- # [16:23] * Joins: aroben (aroben@71.58.77.15)
- # [16:24] <hendry> marcos: ok, wanted to follow up to Rainer on BONDI list RE: appconfig
- # [16:24] <hendry> saying that widget.preferences would be mandatory for a widget runtime
- # [16:24] <hendry> hence appconfig has no use
- # [16:25] <marcos> no, it's not.
- # [16:25] <hendry> though why can't preference be more general
- # [16:25] <marcos> how do you mean?
- # [16:25] <marcos> more general?
- # [16:25] <hendry> so it can read any config entry?
- # [16:26] <marcos> oh, we have other APIs for that
- # [16:26] <marcos> which are kinda dumb... I agree. I would prefer a general config.get("author") or something
- # [16:26] <hendry> argh, htf am i going to resolve the appconfig stuff
- # [16:26] <marcos> but we went with widget.authorInfo, widget.description, widget.blabla
- # [16:27] <hendry> ok, i am still going to ask bondi accept preference element as a requirement in place of appconfig
- # [16:32] <marcos> what is the appconfig?
- # [16:32] <marcos> hendry:
- # [16:33] <hendry> marcos: that bondi thing to read and set config.xml values
- # [16:33] * marcos has not see
- # [16:33] <marcos> n
- # [16:33] <hendry> marcos: you commented on it last week?
- # [16:33] <marcos> hehe,
- # [16:33] <hendry> appconfig widl review
- # [16:34] <marcos> I have a bot that spits venom from the side lines, I don't actually pay attention to what they are talking about
- # [16:34] <hendry> how can preferences by optional?
- # [16:34] <hendry> couldn't some widget rely on that?
- # [16:35] * marcos confused
- # [16:35] <hendry> if a widget has a bad config.xml, the index.html should not be executed right?
- # [16:35] <marcos> right
- # [16:35] <marcos> what is a bad config?
- # [16:36] <hendry> i dunno, id="foo"
- # [16:36] <marcos> no, that's ok
- # [16:36] <marcos> bad config would be a malformed config
- # [16:36] <hendry> id should be anyURI
- # [16:36] <marcos> yes, but if it's not, it won't crash
- # [16:36] <marcos> it just says, meh, and keeps going
- # [16:36] <hendry> so, it'll carry on executing the index.html?
- # [16:37] <marcos> sure
- # [16:37] <hendry> so i had some tests
- # [16:37] <marcos> here we go...
- # [16:37] <hendry> that tested for bad values in the config.xml
- # [16:37] <hendry> assuming that if it ran index.html, it would call a fail ajax script
- # [16:37] <marcos> yes, that is fine. The engine will still respond correctly. Which is to ignore bogus values
- # [16:38] <marcos> like in HTMLs, you don't crash if an <img height="banana">
- # [16:38] <hendry> ok
- # [16:38] <marcos> You just say "meh" and move on
- # [16:38] <hendry> ok
- # [16:38] <hendry> gosh, i hate testing
- # [16:39] * marcos does Nelson point and laugh at hendry
- # [16:39] <hendry> i don't see the point of negative testing config.xml values
- # [16:39] <marcos> You have to for interop
- # [16:40] * marcos will help you out once he finishes the P&C spec
- # [16:40] * Quits: arve (arve@85.89.230.140) (Ping timeout)
- # [16:40] <marcos> There is no point in doing anything ATM because of the i18n model changes
- # [16:40] <hendry> a test like i described, with id=foo and test.js-> fail() is pointless
- # [16:40] <hendry> marcos: ok ok don't worry
- # [16:40] <hendry> there is more of exercise in understanding how everything should work
- # [16:41] <marcos> Yeah, some things are going to be hard to test
- # [16:41] <marcos> using JS at least
- # [16:42] <marcos> because the JS does not interact with aspects of processing in the config doc, etc
- # [16:42] <marcos> But we will get it sorted
- # [16:52] <marcos> hendry: tell me more about this appconfig thing
- # [16:52] <marcos> what are the methods?
- # [16:56] <hendry> http://bondi.omtp.org/apis-current/namespaceorg_1_1omtp_1_1bondi_1_1appconfig.html
- # [16:56] <hendry> get set
- # [16:56] * Quits: Lachy (Lachlan@213.236.208.22) (Quit: This computer has gone to sleep)
- # [16:56] <hendry> it should be just get
- # [16:57] <marcos> how would it work? what do they return?
- # [16:58] <marcos> oohh, I think I see
- # [16:58] <marcos> yeah, you don't need that
- # [16:58] <marcos> use widget.preferences
- # [16:58] <marcos> that API is dumbass
- # [16:58] <marcos> how do you delete something?
- # [16:59] <hendry> yes, there are tons of open questions, Paddy elaborated on the thread
- # [17:00] <hendry> if I could argue a widget runtime would have to have widget.preferences anyway, that would make it easier
- # [17:00] <marcos> BONDI should leave the config stuff to the W3C. If they want something they should ask for it
- # [17:00] <marcos> it does already\
- # [17:00] <marcos> I asked BONDI to review the latest draft
- # [17:01] <marcos> the latest draft of the A&E spec, that is
- # [17:04] <hendry> marcos: oh you said preferences implement Storage
- # [17:04] <marcos> right
- # [17:04] <hendry> you don't reference the W3C Storage spec do you?
- # [17:05] <marcos> we do
- # [17:05] <marcos> http://dev.w3.org/2006/waf/widgets-api/#the-preferences-attribute
- # [17:06] <hendry> oh, ok i was looking in http://dev.w3.org/2006/waf/widgets/#the-preference-element
- # [17:07] * Quits: anne (annevk@94.210.210.44) (Ping timeout)
- # [17:29] * ArtB is now known as ArtB_
- # [17:31] * Joins: Lachy (Lachlan@85.196.122.246)
- # [17:51] * Quits: taf2 (taf2@38.99.201.242) (Quit: taf2)
- # [18:10] * Joins: annevk (opera@94.210.210.44)
- # [18:15] * Quits: shepazu (schepers@128.30.52.30) (Quit: shepazu)
- # [18:54] * Joins: taf2 (taf2@38.99.201.242)
- # [19:06] * Quits: marcos (Marcos@213.236.208.22) (Quit: marcos)
- # [19:08] * Joins: Marcos (Marcos@213.236.208.22)
- # [19:44] * Quits: darobin (darobin@88.162.131.13) (Quit: darobin)
- # [19:55] * Joins: darobin (darobin@88.162.131.13)
- # [19:57] * Quits: darobin (darobin@88.162.131.13) (Quit: darobin)
- # [20:31] * Joins: chaals (chaals@201.19.64.212)
- # [20:31] * ArtB_ is now known as ArtB
- # [20:55] * Joins: arve (arve@84.202.133.45)
- # [21:14] * Quits: tlr (tlr@128.30.52.30) (Quit: tlr)
- # [21:40] * Quits: arve (arve@84.202.133.45) (Client exited)
- # [22:15] * Joins: darobin (darobin@85.169.117.248)
- # [22:26] * Quits: darobin (darobin@85.169.117.248) (Ping timeout)
- # [22:36] * Quits: taf2 (taf2@38.99.201.242) (Quit: taf2)
- # [22:37] * Joins: arve (arve@84.202.133.45)
- # [22:50] * Joins: wellington (chatzilla@201.92.95.29)
- # [22:53] * Joins: darobin (darobin@85.169.117.248)
- # [22:53] * Quits: darobin (darobin@85.169.117.248) (Quit: darobin)
- # [22:59] * Quits: wellington (chatzilla@201.92.95.29) (Quit: ChatZilla 0.9.84 [Firefox 3.0.10/2009042513])
- # [23:39] * Quits: arve (arve@84.202.133.45) (Ping timeout)
- # [23:40] * Joins: taf2 (taf2@68.49.245.59)
- # [23:55] * Quits: aroben (aroben@71.58.77.15) (Ping timeout)
- # Session Close: Wed May 06 00:00:00 2009
The end :)