[widgets] Dig Sig review in prep for LC
Hi Frederick, Some tiny editorial changes I think we should add the following sub-section to the Status of This Document: [[ h3 class=no-num no-tocNote to Last Call Reviewers/h3 pemThis section is non-normative./em/p pThe editors of this specification respond rapidly to all feedback and continuously make corrections to this document. Unless you are reading this document on the date of publication, strong class=redNoteit is extremely likely that this document has been superseded/strong. Instead of reviewing this published draft, please review the a href=http://dev.w3.org/2006/waf/widgets-digsig/;latest editor's draft/a and make sure to cite the date of that draft in the feedback sent to the Web Apps Working Group's public mailing list a href= mailto:public-webapps@w3.org;public-Webapps@w3.org/a. /p pPlease also be sure to check the mailing list a href= http://lists.w3.org/Archives/Public/public-webapps/;archive/a to see if any issues uncovered have already been addressed. To help with cataloging issues, prefix emails to the mailing list with the string samp[widgets]/samp. Any and all feedback is welcomed./p ]] Section 1.1 Namespace prefix wsig: wsig Section 1.3 to the term definition to where the term is defined. 2.0 are addressed in the Widgets 1.0 Requirements [Widgets Requirements] document. - are addressed in the Widgets 1.0 Requirements document [Widgets Requirements]. 3.0 security critical mechanism Can we include a concrete example of such a thing? I'm not sure what a security critical mechanism is. 4.0 Step 6 Numerical order is - dfnNumerical order/dfn is The numerical order is really relevant to processing. I think we should move this paragraph and proceeding paragraph to the top of section 4.0. Their importance is kind of lost where they are right now. 5.1 profile of XML Signature [XMLDSIG11] defined by this specification. - profile of [XMLDSIG11] defined by this specification. contain a dsp:Profile signature properties element compliant with XML Signature Properties [XMLDSIG-Properties] and this specification. - contain a dsp:Profile element compliant with the [XMLDSIG-Properties] specification and this specification. 5.5 The dsp:Identifier signature property is intended to be used to uniquely identify the signature to enable signature management. Who is the subject in this sentence? I.e., used by who? publishers? the UA? users? I think that needs to be made clear. value is unique for the widgets that they sign. value is unique for the widget packages that they sign. 6.1 Signatures generated using key lengths of less than 2048 bits SHOULD NOT be used unless the life time of the signature is less than one year. Again, it is not clear to me who SHOULD NOT be used is directed at? should not be used by the UA? Kind regards, Marcos -- Marcos Caceres http://datadriven.com.au
Re: [DOML3Events] ACTION-267 Proposal for event iterator
also note that this would mean that a web site could try to knock out other web based mashups that it didn't like. i'm sure that browser vendors can provide an api for their debugging clients, but this feature shouldn't be exposed to web content.
WebStorage feedback
On Tue, 7 Apr 2009, João Eiras wrote: Please consider a typical webpage, that on first load, opens a database (using openDatabase) and then creates a read-only transaction to read data to initialize whatever needs initializing. If it's the first time the user opens that webpage, the database that the webpage tries to access effectively does not exist yet and the user agent will have to create it, meaning that that database will be completely empty (no objects nor data). The processing steps for readTransaction are clear though, about calling the apropriate callbacks for the queries, but it also demands, and rightfully so, that a read-only transaction must not modify data. This contradicts a bit the fact that the user agent would need to create the new datafile to represent that database. Such changes are implementation details; whether they are done as part of the openDatabase() call, as part of a transaction, or at some completely other time is not really relevant to the API. Although the specification does not make any direct reference to datafiles, because that's an implementation detail, expecting an empty database for a readTransaction would require the user agent either to optimize this scenario to not execute any sql directly but to call the error callbacks with the apropriate error codes, if the user agent knows in advance that the database is empty, or, the user agent could create an empty datafile which would represent our new empty database, but that's a performance problem in devices with slow file IO. Even if the user agent was not aware of the fact that the database is empty, it would still cause all statements executed within the read-only transaction on our empty database to fail. The situation is analogous to doing a first SELECT on a read-write transaction. However, the select can be interleaved between other DML/DDL statements which create and modify data, so there's no knowledge before hand if a SELECT is going to be executed on read-write transaction on an empty database. In this particular case, the user agent would just report the normal error about querying nonexistent objects. So, I propose the readTransaction function to outright throw an exception IF the database is completely empty (no objects, no data). This would actually makes authors lives easier by getting the error sooner, and make the situation more easily detectable. It would also make implementors lives easier by introducing this optimization on the specification. Not all statements would fail, e.g. a SELECT 1; statement wouldn't fail. For this reason, I don't think it makes sense to fail early here. Similarly, a transaction with no statements wouldn't fail. On Fri, 24 Apr 2009, Anne van Kesteren wrote: We noticed a problem while working on Web Storage. The broadcasting feature allows fork bombing. I personally couldn't think of any other features that allows such a thing. Works against Gecko: http://dump.testsuite.org/2009/storage/demo-001.htm Works against WebKit: http://dump.testsuite.org/2009/storage/demo-001-webkit.htm Internet Explorer seems protected against this particular demo increasing only a slightly in memory usage (though a lot of I/O): http://dump.testsuite.org/2009/storage/demo-001-trident.htm How is this different from making two mutations per mutation event, or calling postMessage() twice for each invokation of the 'message' event, or loading two new iframes every time an iframe's 'load' event fires? Should we really be introducing such a new feature (broadcasting) as part of sessionStorage/localStorage? It seems important for scripts to be able to detect changes. On Fri, 24 Apr 2009, Anne van Kesteren wrote: The storage event currently seems to be dispatched synchronously. Fixed. On Fri, 24 Apr 2009, Anne van Kesteren wrote: There's quite a big interoperability problem with the events. * Per the specification the event is to be dispatched on Window (and does not bubble). * In Firefox it is dispatched on body and then bubbles up to Window. * In WebKit it is dispatched on body (and does not bubble). * In Internet Explorer it is dispatched on document. It would be nice if we can figure out where we want to go in the end. Seems like dispatching it on Window is the best plan in the end. It is unfortunate that the early implementations vary on this, but it's probably my fault (the implementations came along before I sorted out the body/Window event mess). Note that firing on Window means that body onstorage= works, and that capturing event listeners on Window work. So there are at least two ways to catch the event in all otherwise-compliant browsers (and if they're not otherwise compliant, then we have bigger problems anyway). On Mon, 27 Apr 2009, Anne van Kesteren wrote: Consider having two windows A and B where the session history of A
Re: [webidl] definition of const string literal
Cameron McCormack c...@mcc.id.au wrote: (Also I see that you’re using the “string” and “wstring”, and Lwide string values. Are you of the opinion that Web IDL should introduce those instead of DOMString?) Shiki Okasaka sh...@google.com wrote: In my opinion, it would be nice if we can use the keyword 'string' as the same meaning of 'DOMString' in Web IDL since it's not only for DOM specifications. this would be a serious problem for mozilla. In mozilla, 'string' and 'wstring' mean things very different from DOMString, and we can't change that.
Re: [widgets] i18n proposals document
Hi, I need confirmation that I understand the impact of F1 from the Finding missing localized content, specifically how the dynamic setting of the xml:base on the element influences subsequent localized content resolving, so please review my understanding and correct me if I have got it wrong. Is the expectation that the dynamically set xml:base is limited to the element itself and not recursively applied to all other resource resolution? That is, the dynamically set xml:base does not override the base-folder determined by the ua and widget locale matching. From the example (see excerpt from proposal below), the xml:base would be resolved to the widget root for the content element, but not impact the resource resolving for the elements in the index.htm file which reference the a.gif and the b.gif files. These would resolve to the locale/en-us-xx/ locale. Would their xml:base be expected to dynamically be set accordingly? Thanks, Andy Consider the following widget. Assume the widget's locale is en-us-xx and the file the user agent is searching for is index.html. widget.wgt config.xml index.html a.gif b.gif hello/d.gif locales/en-us-xx/a.gif locales/en-us/a.gif locales/en-gb/a.gif locales/en-gb/index.html locales/en/a.gif locales/en/c.gif PROPOSAL F1: The user agent searches for the missing file in the folder hierarchy that matches the widget's locale. If the file is not in the hierarchy of locale folders, then the user agent searches for the file at the root of the widget package. The container for localized content (the folder called locales) is not searched for missing content. If the missing file is found somewhere in the folder hierarchy of locale folders or at the root of the widget, and no xml:base has been explicitly set by the author for this element, then the user agent must set xml:base of that element to be an alternate locale folder, or to the root of the widget package, that contains the file. This is the editor's preferred proposal. Using the example widget above, in the case where the src attribute of the content element is index.html, the user agent would first look in the /locales/en-us-xx, then in /locales/en-us, and then in the /locales/en folder, but would fail to find the file. So then the user agent would search at the root of the widget, where it would find a that matches the file name of the file it is searching for. The user agent now dynamically sets the xml:base of the content element to the root of the widget. -8
Re: [widgets] Dig Sig review in prep for LC
Hi Frederick, Some tiny editorial changes I think we should add the following sub-section to the Status of This Document: [[ h3 class=no-num no-tocNote to Last Call Reviewers/h3 pemThis section is non-normative./em/p pThe editors of this specification respond rapidly to all feedback and continuously make corrections to this document. Unless you are reading this document on the date of publication, strong class=redNoteit is extremely likely that this document has been superseded/strong. Instead of reviewing this published draft, please review the a href=http://dev.w3.org/2006/waf/widgets-digsig/;latest editor's draft/a and make sure to cite the date of that draft in the feedback sent to the Web Apps Working Group's public mailing list a href= mailto:public-webapps@w3.org;public-Webapps@w3.org/a. /p pPlease also be sure to check the mailing list a href= http://lists.w3.org/Archives/Public/public-webapps/;archive/a to see if any issues uncovered have already been addressed. To help with cataloging issues, prefix emails to the mailing list with the string samp[widgets]/samp. Any and all feedback is welcomed./p ]] Well... Doesn't Last Call suggest that you're actually beyond the phase of rapid changes?
[webidl] Callback confusion
Hi,
I'm confused with http://dev.w3.org/2006/webapi/WebIDL/#Callback
It seems that it is not possible to write:
t.addListener(function() { ... });
without throwing a typeError when the callback is thrown. Does that mean that
you can never write an IDL
that will let you write foo(function() {...};) without errors, and that you can
only write it as foo({ baz: function() {...}}); ?
Also, the code labeled /* 2 */ is not explained. Does that mean that that line
does nothing?
Cheers,
Max.
Re: [widgets] Dig Sig review in prep for LC
On 29 Apr 2009, at 13:55, Marcos Caceres wrote: Well... Doesn't Last Call suggest that you're actually beyond the phase of rapid changes? LOL! hell no, that's when most changes happen because it's the only time people pay enough attention to do an actual review. That's why Last Call should really be called First Call :) I guess I'd rather see several last calls with just a month between them, than setting an expectation that lots of rapid changes occur in something that people are supposed to take some time to do a final review of. The kind of note that you're suggesting can very well cause people to *still* not pay attention to the draft, and wait till something more stable comes out. Say hello to substantive comments in CR. ;)
Re: [widgets] Dig Sig review in prep for LC
+1 I don't see the need for that paragraph. regards, Frederick Frederick Hirsch Nokia On Apr 29, 2009, at 6:36 AM, ext Thomas Roessler wrote: Hi Frederick, Some tiny editorial changes I think we should add the following sub-section to the Status of This Document: [[ h3 class=no-num no-tocNote to Last Call Reviewers/h3 pemThis section is non-normative./em/p pThe editors of this specification respond rapidly to all feedback and continuously make corrections to this document. Unless you are reading this document on the date of publication, strong class=redNoteit is extremely likely that this document has been superseded/strong. Instead of reviewing this published draft, please review the a href=http://dev.w3.org/2006/waf/widgets- digsig/latest editor's draft/a and make sure to cite the date of that draft in the feedback sent to the Web Apps Working Group's public mailing list a href= mailto:public-webapps@w3.org;public-Webapps@w3.org/a. /p pPlease also be sure to check the mailing list a href= http://lists.w3.org/Archives/Public/public-webapps/;archive/a to see if any issues uncovered have already been addressed. To help with cataloging issues, prefix emails to the mailing list with the string samp[widgets]/samp. Any and all feedback is welcomed./p ]] Well... Doesn't Last Call suggest that you're actually beyond the phase of rapid changes?
Re: [widgets] Dig Sig review in prep for LC
On 4/29/09 2:32 PM, Frederick Hirsch wrote: +1 I don't see the need for that paragraph. Ok, no probs. Leave it out. Kind regards, Marcos
Re: [widgets] Dig Sig review in prep for LC
comments inline, including proposals. thanks for the review regards, Frederick Frederick Hirsch Nokia On Apr 29, 2009, at 4:01 AM, ext Marcos Caceres wrote: Hi Frederick, Some tiny editorial changes I think we should add the following sub-section to the Status of This Document: [[ h3 class=no-num no-tocNote to Last Call Reviewers/h3 pemThis section is non-normative./em/p pThe editors of this specification respond rapidly to all feedback and continuously make corrections to this document. Unless you are reading this document on the date of publication, strong class=redNoteit is extremely likely that this document has been superseded/strong. Instead of reviewing this published draft, please review the a href=http://dev.w3.org/2006/waf/widgets-digsig/;latest editor's draft/a and make sure to cite the date of that draft in the feedback sent to the Web Apps Working Group's public mailing list a href= mailto:public-webapps@w3.org;public-Webapps@w3.org/a. /p pPlease also be sure to check the mailing list a href= http://lists.w3.org/Archives/Public/public-webapps/;archive/a to see if any issues uncovered have already been addressed. To help with cataloging issues, prefix emails to the mailing list with the string samp[widgets]/samp. Any and all feedback is welcomed./p ]] I think we should use standard last call boilerplate. If it isn't ready for last call then maybe we should wait. Section 1.1 Namespace prefix wsig: wsig I think wsig: is clearer to the reader so would not like to do this one. Section 1.3 to the term definition to where the term is defined. ok 2.0 are addressed in the Widgets 1.0 Requirements [Widgets Requirements] document. - are addressed in the Widgets 1.0 Requirements document [Widgets Requirements]. ok 3.0 security critical mechanism Can we include a concrete example of such a thing? I'm not sure what a security critical mechanism is. I suggest we remove Trust in a certificate is established through a security critical mechanism implemented by the user agent, which is out of scope for this specification. Mark, do you have a better suggestion? 4.0 Step 6 Numerical order is - dfnNumerical order/dfn is The numerical order is really relevant to processing. I think we should move this paragraph and proceeding paragraph to the top of section 4.0. Their importance is kind of lost where they are right now. there are only 7 steps, less than a page. I doubt it will get lost. I suggest leaving this alone. ok with dfn. 5.1 profile of XML Signature [XMLDSIG11] defined by this specification. - profile of [XMLDSIG11] defined by this specification. I think the english XML Signature which I though makes it more readable. I guess we have different styles in mind, I prefer english + Reference, alternative is reference only. I can make this change for consistency. contain a dsp:Profile signature properties element compliant with XML Signature Properties [XMLDSIG-Properties] and this specification. - contain a dsp:Profile element compliant with the [XMLDSIG-Properties] specification and this specification. ok, highlighting term 5.5 The dsp:Identifier signature property is intended to be used to uniquely identify the signature to enable signature management. Who is the subject in this sentence? I.e., used by who? publishers? the UA? users? I think that needs to be made clear. how about The signer uses the dsp:Identifier signature property to uniquely identify the signature to enable signature management. (you don't like passive voice? :) value is unique for the widgets that they sign. value is unique for the widget packages that they sign. ok 6.1 Signatures generated using key lengths of less than 2048 bits SHOULD NOT be used unless the life time of the signature is less than one year. Again, it is not clear to me who SHOULD NOT be used is directed at? should not be used by the UA? The signer SHOULD NOT generate signatures using key lengths of less than 2048 bits unless the life time of the signature is less than one year. By the way, shouldn't this be a MUST NOT? Kind regards, Marcos thanks -- Marcos Caceres http://datadriven.com.au
Re: [widgets] Dig Sig review in prep for LC
Hi, I support all the recommendations/rejections below. Kind regards, Marcos On Wed, Apr 29, 2009 at 2:42 PM, Frederick Hirsch frederick.hir...@nokia.com wrote: comments inline, including proposals. thanks for the review regards, Frederick Frederick Hirsch Nokia On Apr 29, 2009, at 4:01 AM, ext Marcos Caceres wrote: Hi Frederick, Some tiny editorial changes I think we should add the following sub-section to the Status of This Document: [[ h3 class=no-num no-tocNote to Last Call Reviewers/h3 pemThis section is non-normative./em/p pThe editors of this specification respond rapidly to all feedback and continuously make corrections to this document. Unless you are reading this document on the date of publication, strong class=redNoteit is extremely likely that this document has been superseded/strong. Instead of reviewing this published draft, please review the a href=http://dev.w3.org/2006/waf/widgets-digsig/;latest editor's draft/a and make sure to cite the date of that draft in the feedback sent to the Web Apps Working Group's public mailing list a href= mailto:public-webapps@w3.org;public-Webapps@w3.org/a. /p pPlease also be sure to check the mailing list a href= http://lists.w3.org/Archives/Public/public-webapps/;archive/a to see if any issues uncovered have already been addressed. To help with cataloging issues, prefix emails to the mailing list with the string samp[widgets]/samp. Any and all feedback is welcomed./p ]] I think we should use standard last call boilerplate. If it isn't ready for last call then maybe we should wait. Section 1.1 Namespace prefix wsig: wsig I think wsig: is clearer to the reader so would not like to do this one. Section 1.3 to the term definition to where the term is defined. ok 2.0 are addressed in the Widgets 1.0 Requirements [Widgets Requirements] document. - are addressed in the Widgets 1.0 Requirements document [Widgets Requirements]. ok 3.0 security critical mechanism Can we include a concrete example of such a thing? I'm not sure what a security critical mechanism is. I suggest we remove Trust in a certificate is established through a security critical mechanism implemented by the user agent, which is out of scope for this specification. Mark, do you have a better suggestion? 4.0 Step 6 Numerical order is - dfnNumerical order/dfn is The numerical order is really relevant to processing. I think we should move this paragraph and proceeding paragraph to the top of section 4.0. Their importance is kind of lost where they are right now. there are only 7 steps, less than a page. I doubt it will get lost. I suggest leaving this alone. ok with dfn. 5.1 profile of XML Signature [XMLDSIG11] defined by this specification. - profile of [XMLDSIG11] defined by this specification. I think the english XML Signature which I though makes it more readable. I guess we have different styles in mind, I prefer english + Reference, alternative is reference only. I can make this change for consistency. contain a dsp:Profile signature properties element compliant with XML Signature Properties [XMLDSIG-Properties] and this specification. - contain a dsp:Profile element compliant with the [XMLDSIG-Properties] specification and this specification. ok, highlighting term 5.5 The dsp:Identifier signature property is intended to be used to uniquely identify the signature to enable signature management. Who is the subject in this sentence? I.e., used by who? publishers? the UA? users? I think that needs to be made clear. how about The signer uses the dsp:Identifier signature property to uniquely identify the signature to enable signature management. (you don't like passive voice? :) value is unique for the widgets that they sign. value is unique for the widget packages that they sign. ok 6.1 Signatures generated using key lengths of less than 2048 bits SHOULD NOT be used unless the life time of the signature is less than one year. Again, it is not clear to me who SHOULD NOT be used is directed at? should not be used by the UA? The signer SHOULD NOT generate signatures using key lengths of less than 2048 bits unless the life time of the signature is less than one year. By the way, shouldn't this be a MUST NOT? Kind regards, Marcos thanks -- Marcos Caceres http://datadriven.com.au -- Marcos Caceres http://datadriven.com.au
[widgets] Draft Agenda for 30 April 2009 Voice Conference
Below is the draft agenda for the April 30 Widgets Voice Conference (VC). Inputs and discussion before the meeting on all of the agenda topics via public-webapps is encouraged (as it can result in a shortened meeting). Logistics: Time: 22:00 Tokyo; 16:00 Helsinki; 15:00 Paris; 14:00 London; 09:00 Boston; 06:00 Seattle Duration = 90 minutes Zakim Bridge +1.617.761.6200, conference 9231 (WAF1) IRC channel = #wam; irc.w3.org:6665 Confidentiality of minutes = Public Agenda: 1. Review and tweak agenda 2. Announcements 3. PC spec http://dev.w3.org/2006/waf/widgets/ a. access element; comments from http://lists.w3.org/Archives/Public/public-webapps/2009AprJun/ 0291.html b. L10N model; get agreement on the various proposals: http://dev.w3.org/cvsweb/2006/waf/widgets/i18n.html Francois: http://lists.w3.org/Archives/Public/public-webapps/ 2009AprJun/0350.html Andrew: http://lists.w3.org/Archives/Public/public-webapps/2009AprJun/ 0393.html c. Security related issues with core Widgets specs (from Thomas): http://lists.w3.org/Archives/Public/public-webapps/2009AprJun/ 0370.html 4. AE spec http://dev.w3.org/2006/waf/widgets-api/ a. Comments from Rainer: http://lists.w3.org/Archives/Public/public-webapps/2009AprJun/ 0335.html b. Per-instance Storage discussion; need resolution http://lists.w3.org/Archives/Public/public-webapps/2009AprJun/ 0301.html c. What needs to be done before publishing a LCWD? 5. AOB
Re: [webidl] Callback confusion
2009/4/29 Max Froumentin max...@opera.com:
Hi,
I'm confused with http://dev.w3.org/2006/webapi/WebIDL/#Callback
It seems that it is not possible to write:
t.addListener(function() { ... });
without throwing a typeError when the callback is thrown. Does that mean that
you can never write an IDL
that will let you write foo(function() {...};) without errors, and that you
can only write it as foo({ baz: function() {...}}); ?
It throws a TypeError if the interface expected by addListener is
[Callback=PropertyOnly], else it will work.
Also, the code labeled /* 2 */ is not explained. Does that mean that that
line does nothing?
It means that when it is a function but implements the interface
through property assignment, the function takes precedence when
converted to an host object.
Cheers,
Max.
Giovanni
Re: Storage 'length' and enumeration
Ian Hickson wrote: On Tue, 28 Apr 2009, John J. Barton wrote: And then afterwards the |length| is ? one? three? One. If I iterate for(var i = 0; i sesssionStore.length; i++) foo(i, sessionStore[i]); what can I expect in foo()? (0, null), (1, null), (2, "2") or (0, "2")? or ? (0, "2"). I reiterate my criticism: using a length property in this type is inconsistent with _javascript_ and with developers expectations about objects. Every time we use this object we will make pointless mistakes because the type mimics arrays only partially and we won't be able to recall which part it imitates. A simple change from |length| to a method call like getNumberOfItems() would prevent this co-incidental mimicry and make the standard better. jjb
Preferences for the I18N model
Hi, here are my personal preferences for the I18N model[0]. - Folder-based localization: A2 (editor's choice) I don't feel strongly about this choice. I prefer it because it is more flexible and more powerful, but I would understand if implementers felt it did a bit more than necessary (I believe it is possible if needed to start with A1 and transition to A2 in future). Caveat: within the A2 option, I do not understand if the following: locales/x/ locales/x-dahut/ locales/x-nessie/ causes x-dahut and x-nessie to inherit the content from x. Since x- is used for private codes, I don't think that they should (neither should i-, any primary subtag in the qaa- to qtz- range, nor any primary subtag that is four letters long or longer than eight letters). The BCP47 lookup algorithm handles this (or at least part of it), but I'm unsure that it's enough for our purposes — we should ask. - The user agent's locale: B1 (editor's choice) I *strongly* support this option. It may be slightly more complex but it matches how this is resolved over HTTP. Applications that act as if users were only able to use one language are always wrong and badly broken (I'm looking at you, Apple spell checker, Nokia T9, etc.). - Deriving the widget's locale: C1 (editor's choice) The way in which the BCP47 lookup algorithm is expected to work could be slightly clarified; i.e. if I'm looking for en-us and in document (or directory) order I have en then en-us, then en-us will match because it is tried first for the entire list (en would match on a second pass, if en-us were not defined). Note that the BCP47 lookup algorithm specifies that a default value is returned if nothing matches, to be selected. We should make it clear that in our case the default value returned for the locale when nothing matches should be , as that matches xml:lang (and sort of makes sense in relationship to the locale directories). I point this out because one of the options is returning i-default, which could confusingly lead to a locales/i-default/ directory being selected by some implementations. - Possible representations of the widget's locale: D2 (editor's choice) I could live with D3 too, but it seems too complicated for real-world use. D1 makes it more painful to produce localised content. - Dereferencing URIs in Configuration Documents: something else I don't think that either of the provided E options is good. I think that the base URI for a widget resource should not include locale information. Assuming: widget.wgt config.xml index.html locales/en/index.html locales/fr/index.html and three locales en, fr, es, the start content resource would *always* have a document URL of widget://UUDI/index.html. If the locale changes (even at runtime) the document URL does not. What that content is *resolved* to inside the archive changes with the locale, but not the URL. The justification behind this approach is that: a) locales should be transparent, and b) there is no requirement to have the widget URI map *directly* unto the widget's structure. In fact, it is probably best if it's not possible inside locales/en/index.html to go a href='../ fr/index.html'Frog version/a. We can put that in the widget URI document, or somewhere else (I'm not sure where it fits). - Finding missing localized content: something else I think that the F options are wrong for reasons similar to those expressed in the previous section. I think that for all intents and purposes, the user agent should behave as if content from the most specific locale had been copied into less specific locales recursively until they are copied to the root, and the locales directory is discarded. For instance, assuming: widget.wgt config.xml index.html d.svg locales/en-gb-xx/a.svg locales/en-gb-xx/b.svg locales/en-gb/b.svg locales/en-gb/c.svg locales/en/index.html After applying the above algorithm with a UA locale of en-gb-xx we would have widget content equivalent to: widget.wgt config.xml index.html [from locales/en] a.svg [from locales/en-gb-xx] b.svg [from locales/en-gb-xx] c.svg [from locales/en-gb] d.svg [from the root] The way this is defined is that a URI space is created that has the following resolution in place: widget://UUID/index.html - locales/en/index.html widget://UUID/a.svg - locales/en-gb-xx/a.svg widget://UUID/b.svg - locales/en-gb-xx/b.svg widget://UUID/c.svg - locales/en-gb/c.svg widget://UUID/d.svg - index.html I believe that this approach is both cleaner and more powerful. Besides, it makes specifying widget URI resolution easier :) We just have to agree on whether that's defined in the widgets URI specification or in P+C. I'm happy to put it in the former (but I'll need to reference the I18N model from P+C so it may be
Widget URI ED
Hi all, I've made a first pass at an ED for widget URIs (which is needed, as you can tell from the I18N discussion). It's in need of tightening up editorially wise but the basic ideas are there: http://dev.w3.org/2006/waf/widgets-uri/ Share and Enjoy! -- Robin Berjon - http://berjon.com/ Feel like hiring me? Go to http://robineko.com/
[widgets] dig sig and requirements ready for pub!
Widgets dig sig and requirements are ready to be published. Widgets dig sig going to LC! Hoping for feedback (yes, that means you Mozilla guys:)) http://dev.w3.org/2006/waf/widgets-digsig/ http://dev.w3.org/2006/waf/widgets-reqs/ If all goes to plan, they will be published tomorrow. Kind regards, Marcos -- Marcos Caceres http://datadriven.com.au
Re: I18N issue: case-sensitivity of locale subdirectories
On Apr 29, 2009, at 10:16 AM, ext Robin Berjon wrote: There are multiple options: b) we select an order of priority and we only consider one (the first to match); ... I don't have a strong opinion on this, but I do I have a preference for a rule based on (b): if multiple locale subdirectories have the same case-insensitive name, then the one that comes first in ASCII- code order (e.g. in order: EN, En, eN, en) is used and the others are ignored. The argument in favour of only using one is that we already have to merge multiple directories, and adding one merge operation for what is in all probability a user error seems like too much complexity for little value (I'm happy to be contradicted by implementers however). Picking ASCII-code order is based on the fact that the directory names must be ASCII here (the others must be discarded), and picking the first is arbitrary. Thoughts? b) seems like a reasonable choice. I wonder if the I18N WG has any related guidelines recommendations we should consider. -Regards, Art Barstow
Re: Storage 'length' and enumeration
Ian Hickson wrote: On Wed, 29 Apr 2009, John J. Barton wrote: I reiterate my criticism: using a length property in this type is inconsistent with _javascript_ and with developers expectations about objects. Every time we use this object we will make pointless mistakes because the type mimics arrays only partially and we won't be able to recall which part it imitates. A simple change from |length| to a method call like getNumberOfItems() would prevent this co-incidental mimicry and make the standard better. The Storage object works like an HTMLCollection object except that you can also add items, and except that indexing by number returns the key, not the value, since otherwise there'd be no way to know which keys were being returned. I agree that it's not like an Array, but just having a "length" property doesn't mean it works like an Array -- there are lots of host objects in the DOM with "length" properties. Yes and Firebug has to have special code for HTMLCollection because this mistake was made in the past. Now we will have to have different special code for Storage. Rather than modeling new API on old mistakes, consider learning from the past experience and take a direction that developers will find less confusing. Pseudo-arrays with "except... this and that" makes APIs intricate and puzzling. A simpler and less ambiguous approach would be better in my opinion. jjb
Re: Storage 'length' and enumeration
On Wed, 29 Apr 2009, John J. Barton wrote: I reiterate my criticism: using a length property in this type is inconsistent with Javascript and with developers expectations about objects. Every time we use this object we will make pointless mistakes because the type mimics arrays only partially and we won't be able to recall which part it imitates. A simple change from |length| to a method call like getNumberOfItems() would prevent this co-incidental mimicry and make the standard better. The Storage object works like an HTMLCollection object except that you can also add items, and except that indexing by number returns the key, not the value, since otherwise there'd be no way to know which keys were being returned. I agree that it's not like an Array, but just having a length property doesn't mean it works like an Array -- there are lots of host objects in the DOM with length properties. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: WebStorage feedback
On Wed, Apr 29, 2009 at 1:30 AM, Ian Hickson i...@hixie.ch wrote: I've changed it a bit, because it seems UAs are likely to still want a per-origin limit. But I'm not really sure what to suggest that's more concrete that the vague handwaving that is there now. Yeah, I'm not sure how to guard against that either. :) By the way, there is a typo in this sentence: A mostly arbitrary limit of five megabytes per origin is recommended. Implementation feedback is welcome and will be used to update this suggestion in _the_ future. Adam
Re: Storage 'length' and enumeration
On Wed, 29 Apr 2009 20:51:33 +0200, John J Barton johnjbar...@johnjbarton.com wrote: Yes and Firebug has to have special code for HTMLCollection because this mistake was made in the past. Now we will have to have different special code for Storage. Rather than modeling new API on old mistakes, consider learning from the past experience and take a direction that developers will find less confusing. Pseudo-arrays with except... this and that makes APIs intricate and puzzling. A simpler and less ambiguous approach would be better in my opinion. Is there any type of object that holds a collection that does not use .length? Seems a bit weird to break consistency here in my opinion. -- Anne van Kesteren http://annevankesteren.nl/
Re: Storage 'length' and enumeration
On Wed, 29 Apr 2009, John J Barton wrote: Yes and Firebug has to have special code for HTMLCollection because this mistake was made in the past. Now we will have to have different special code for Storage. Rather than modeling new API on old mistakes, consider learning from the past experience and take a direction that developers will find less confusing. Pseudo-arrays with except... this and that makes APIs intricate and puzzling. A simpler and less ambiguous approach would be better in my opinion. It's not an array or a pseudo-array. It's an enumerable JS host object. Firefox will have to have special code to implement Storage anyway; why is more special code to show it in Firebug a bad thing? In fact, it's probably a good thing, since for Storage you probably don't want to be showing the data in the debugger all the time anyway (since that has performance implications). -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: WebStorage feedback
On Wed, 29 Apr 2009, Adam Barth wrote: By the way, there is a typo in this sentence: A mostly arbitrary limit of five megabytes per origin is recommended. Implementation feedback is welcome and will be used to update this suggestion in _the_ future. Thanks, fixed. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: Storage 'length' and enumeration
Ian Hickson wrote: On Tue, 28 Apr 2009, John J. Barton wrote: I could not figure out from the WebIDL what happens in this case: sessionStore[2] = howdy; // no other keys in sessionStore I guess this does not work like Javascript arrays or objects, rather I expect it fails? It works, it just sets the key 2 to the value howdy. (Modulo some WebIDL and WebStorage IDL bugs that I will report separately, oops.) sessionStore[2] = howdy; print(sessionStore[2]); // prints null? print(sessionStore[2]); // prints howdy To my knowledge that's not consistent with any other object or interface in the browser. Sean
Re: Storage 'length' and enumeration
Ian Hickson wrote: On Wed, 29 Apr 2009, John J Barton wrote: Yes and Firebug has to have special code for HTMLCollection because this mistake was made in the past. Now we will have to have different special code for Storage. Rather than modeling new API on old mistakes, consider learning from the past experience and take a direction that developers will find less confusing. Pseudo-arrays with "except... this and that" makes APIs intricate and puzzling. A simpler and less ambiguous approach would be better in my opinion. It's not an array or a pseudo-array. It's an enumerable JS host object. So why call the property |length|? Wouldn't an enumerable JS host object be just as fabulous with getNumberOfItems()? But the part that has me confused is maybe just me being dumb. I just have a hard time with: sessionStorage[2] = "foo"; // set the key |2| to value "foo". then var x = sessionStorage[2]; // null? "foo"? var y = sessionStorage[0]; // "2" I'm thinking: why do I have to think so hard about this? It should be just an associative array. Firefox will have to have special code to implement Storage anyway; why is more special code to show it in Firebug a bad thing? In fact, it's probably a good thing, since for Storage you probably don't want to be showing the data in the debugger all the time anyway (since that has performance implications). Firebug shows objects from Firefox to developers. The appropriate display format for objects depends on the character of the objects and the needs of developers. For example, arrays are shown in square brackets with the first few entries, ["foo", "bar", ...]. HTML Elements are shown with their nodeName and id if any. In this way developers can quickly get an idea of the nature of the object, and perhaps drill down for more information. How many display formats should be created? One for every kind of object is simply impractical. Even if time allowed to create formats for all the built-in types, all the DOM types, all the library types (prototype, jquery, dojo,...) etc, there would still be user types. So you have to create categories of representations that cover the important cases. Firebug has about thirty. Now given an object, how do we assign it to one of these thirty representations? The only possibility is to examine the properties of the object. Since for sure the _javascript_ built in Array type has a |length| and since any type with a length property is likely to be designed to be array-like, the tests for representation use the existence of a length property that is a finite number as part of its test. Of course there are objects that are not arrays and yet have length, eg Strings. Firebug has a separate representation to avoid ["t", "h", "i", "s"]. Since Storage has a length it was originally appearing in Firebug as []. If your API was such that sessionStorage[i] gave the i-th entry, a key, value pair, then the array representation would be already working for us. I hope this makes the issues clearer. jjb
Re: Storage 'length' and enumeration
Sean Hogan wrote: sessionStore[2] = howdy; print(sessionStore[2]); // prints null? Where, exactly? That gives howdy in Gecko, at least. At least with s/sessionStore/window.sessionStorage/. -Boris
Re: Storage 'length' and enumeration
Anne van Kesteren wrote: On Wed, 29 Apr 2009 20:51:33 +0200, John J Barton johnjbar...@johnjbarton.com wrote: Yes and Firebug has to have special code for HTMLCollection because this mistake was made in the past. Now we will have to have different special code for Storage. Rather than modeling new API on old mistakes, consider learning from the past experience and take a direction that developers will find less confusing. Pseudo-arrays with except... this and that makes APIs intricate and puzzling. A simpler and less ambiguous approach would be better in my opinion. Is there any type of object that holds a collection that does not use .length? Seems a bit weird to break consistency here in my opinion. Consistency is exactly not wanted, because it creates the impression of an array-like access pattern where there is not one. sessionStorage[2] is not the third item stored. Actually I don't know what it is, I'm confused. There are lots of on-line articles explaining Javascript arrays versus associative arrays (objects). By having a type which is an associative array -- Storage -- share a property name with Array just makes matters worse. jjb
Re: Storage 'length' and enumeration
Boris Zbarsky wrote: Sean Hogan wrote: sessionStore[2] = howdy; print(sessionStore[2]); // prints null? Where, exactly? That gives howdy in Gecko, at least. At least with s/sessionStore/window.sessionStorage/. -Boris I was following the discussion, and the point is that array-like behavior is implied but not consistently delivered. Anyway, as you point out, for this interface Firefox gives precedence to NameGetters over IndexGetters. In the spec it doesn't seemed defined. FYI, other collections in Firefox give precedence to IndexGetters.
Re: Storage 'length' and enumeration
On Wed, 29 Apr 2009, John J Barton wrote: So why call the property |length|? Wouldn't an enumerable JS host object be just as fabulous with getNumberOfItems()? All the other host objects use |length|. But the part that has me confused is maybe just me being dumb. I just have a hard time with: sessionStorage[2] = foo; // set the key |2| to value foo. then var x = sessionStorage[2]; // null? foo? var y = sessionStorage[0]; // 2 I'm thinking: why do I have to think so hard about this? It should be just an associative array. You only have to think hard about this if you use numeric keys and use the implied accessors. Just use .setItem(2) and .getItem(2), or use a non-numeric key, and then there's no confusion. Firebug shows objects from Firefox to developers. The appropriate display format for objects depends on the character of the objects and the needs of developers. For example, arrays are shown in square brackets with the first few entries, [foo, bar, ...]. HTML Elements are shown with their nodeName and id if any. In this way developers can quickly get an idea of the nature of the object, and perhaps drill down for more information. How many display formats should be created? One for every kind of object is simply impractical. Even if time allowed to create formats for all the built-in types, all the DOM types, all the library types (prototype, jquery, dojo,...) etc, there would still be user types. So you have to create categories of representations that cover the important cases. Firebug has about thirty. Now given an object, how do we assign it to one of these thirty representations? The only possibility is to examine the properties of the object. That's no the only possibility by a long shot. In fact it's not even a particularly good option; I would recommend using instanceof and the like instead. Of course there are objects that are not arrays and yet have length, eg Strings. There are lots of objects that are not arrays (or should not be rendered as arrays) and yet have length. Collections, TimeRanges, select elements, Window objects, History, CanvasPixelArrays, etc. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: Storage 'length' and enumeration
On Thu, 30 Apr 2009, Sean Hogan wrote: sessionStore[2] = howdy; print(sessionStore[2]); // prints null? print(sessionStore[2]); // prints howdy To my knowledge that's not consistent with any other object or interface in the browser. Unless I'm mistaken, they both print howdy. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: Storage 'length' and enumeration
Ian Hickson wrote: There are lots of objects that are not arrays (or should not be rendered as arrays) and yet have length. Collections, TimeRanges, select elements, Window objects, History, CanvasPixelArrays, etc. I'm not sure about all those objects, but my (incomplete) testing of HTML*Collections indicates that when accessed using array notation: object[index]; where index object.length they behave as a readonly array. Which has the fortuitous by-product of allowing the object to work with Array.forEach(), etc. Storage objects have a length property and can be accessed with array notation. They look like they should work with Array generic methods... and they do... except they aren't reliable if you use numeric keys... but they don't even give an error message. I would suggest one of: 1. When accessed as an array they are treated as a readonly array. i.e. MUST use getItem(), setItem() for numeric keys 2. Treat it as an associative array. Change the name of the length property.
