Re: HTML 5 Database Storage Does Not Enable Chaining Transactions
On Sat, 4 Apr 2009, Doug Reeder wrote:
The scenario where I need to use HTML 5 Database storage requires
storing a tree of data. Each item has a unique id, generated by the
database. Child nodes have a parentId field which points to their
parent ID. Creating the records for a new tree in the database requires
multiple transactions. First, the root item must be created. When the
callback returns, the children of the root item can be created, because
the id of the root item is now known. For each child, when the
appropriate callback returns, the children of the child can be created,
because their parent IDs are now known, and so forth.
Minimizing the number of transactions (and thus the overall time to
create a database) requires there be multiple transactions outstanding
at any given time. Thus, when a callback function is called, it needs
to determine _which_ transaction has completed. The current version of
the HTML 5 Database storage spec does not make this easy. It is
straightforward for my app to generate a unique ID for each transaction,
but the spec provides no way to pass this to the callbacks. In
JavaScript, I can add an id field to the transaction object, but then
the _same_ id gets passed to each statement callback, and the
transaction object is not passed _at all_ to the transaction success
callback.
I'm sure there are other scenarios where it would be useful for a
statement callback to know which statement has completed, and for a
transaction callback to know which transaction has just completed.
Don't closures do what you want? Instead of always using the same function
as the callback, create a new function each time, with that function
having the identifier in question, as in:
function getCallback(id) {
return function (transaction) {
// ... the callback ...
};
}
//... n is some identifier
db.transaction(getCallback(n));
--
Ian Hickson U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,.
Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
[widgets] PC LC comments on I18N/L10N
Marcos, all, here's a bunch of comments related to the I18N/L10N related parts of the Widgets 1.0: Packaging and Configuration spec (Last Call i.e. Working Draft 28 May 2009). /1/ Order of material From an editorial standpoint, I think that the 7.2 Examples subsection should really be the last one in this section. Information about element-based localization, which now is 8.15, should appear in section 7, because the concepts are used in Section 8 before they are even defined. It would be good to have all related info in the same section. My suggestion for the organization of the material is: 7 Internationalization and localization 7.1 Localization guidelines 7.2 Folder-based localization (used to be 7.3) 7.3 Element-based localization (used to be 8.15) 7.4 Localization examples (used to be 7.2 Examples, note new name) This would make the material flow better and have all the concepts defined before they are used. Also, the whole of Section 7 should actually appear right before the processing steps (i.e., after the current Section 8). /2/ Content of examples The localization examples are non-normative, but many developers are going to study them closely, so it pays to fine-tune them a little (and fix a few bugs). In the simple example, the second file /sp/index.html should be labeled /locales/es/index.html. Similarly, in the complex example, /locales/sp/ should be /locales/es. The complex example refers to several files which really have the same purpose. I think they should also have the same name, otherwise they cannot be found by the same reference. That is, /locales/es/gatos.html should be called /locales/es/cats.html. Or is it intentional? In Fallback Behaviour Example, first paragraph, last sentence should read: The purpose of this 'fallback' model is to reduce the number of files that need to be created in order to achieve localization of a widget package. (remove 'n' from 'then', add 'in order') /3/ Folder-based localization Suggested addition to the authoring guideline: A Conformance Checker (CC) SHOULD issue a warning if there are empty locale folders in the widget package. This statement in the authoring guideline is puzzling: '[That is,] authors cannot simply put shared files into a language level folder, but need to put all files needed into the language level folder for the widget to work (for example, having a.gif in both /locales/zh-Hans/ folder and locales/zh).' Isn't this the opposite of what is supposed to happen in the fallback model? If the same a.gif is good for both zh-Hans and zh, it should be possible for the author to include it just once in /locales/zh. If the user's language list includes 'zh-Hans', it will also include 'zh', as per Step 5. So a.gif will be found eventually. Replace 'shared1.gif, shared2.gif' with 'shared1.gif and shared2.gif'. Priority is probably a bad term to use with regard to localized folders. /4/ The xml:lang attribute Does the XML specification state that the values of xml:lang attributes must be unique across instances of the same element? If yes, it is probably redundant to repeat that in the context of all the elements in the configuration document. If not, the statement about uniqueness could still be factored out, for example to section 8.4, to avoid repetition. /5/ Processing steps Step 3: the concept of localized config doc appears in the Configuration Defaults table, but that doesn't seem to exist anymore. (See also Step 6.) Step 5: replace unprocessed locales lists with unprocessed locales list throughout. Consider replacing user agent's locales with user agent locales throughout the spec. In the first example of Step 5, why would en and en-au be swapped around when decomposed? Would 'canonicalization' be a more suitable term here than 'decomposition'? /6/ Runtime resolution of localized resources What specification should describe how a reference to a resource (which could be in a localized folder) is resolved at runtime, based on the user's language range? That is not quite in the domain of the packaging specification, given that it is runtime behavior. This functionality is sketched in the fallback behavior example, but it is non-normative. Thanks for considering these comments. Best regards, Jere @ Nokia
RE: [widgets] What does it mean to have an unavailable API
Hi Scott, I can see the UC for requestFeature, though its not something we'd ever expect to use - we'd stick to just static feature declarations, as we have no way of injecting scripts into instances after they've already launched. There is an ongoing debate about requestFeature(). BONDI spec is approaching both widgets and websites and basically requestFeature() is planned to be primarily used only by websites. requestFeature() is present in general WebIDL, we may need some prose in case its use is constrained. The next debate on this topic in BONDI is planned to happen soon. The output will definitely by provided to this mailing list asap, I assume. Thanks. Kind regards, Marcin Marcin Hanclik ACCESS Systems Germany GmbH Tel: +49-208-8290-6452 | Fax: +49-208-8290-6465 Mobile: +49-163-8290-646 E-Mail: marcin.hanc...@access-company.com -Original Message- From: Scott Wilson [mailto:scott.bradley.wil...@gmail.com] Sent: Tuesday, June 02, 2009 5:41 PM To: Marcin Hanclik Cc: Henri Sivonen; public-webapps Subject: Re: [widgets] What does it mean to have an unavailable API Hi Marcin, Yes, on (1); the Google example I was referring to does the same. So, for example, analytics is the feature name, but this means the whole module, which includes a couple of JS libs and a range of functions. For hasFeature() the only UC I can see is if your Widget declares a Feature, but doesn't require it (REQUIRED=false), but can make use of it for added functionality if it is available. (Sorry Marcos, just remembered this one - don't get rid of hasFeature() yet!) I can see the UC for requestFeature, though its not something we'd ever expect to use - we'd stick to just static feature declarations, as we have no way of injecting scripts into instances after they've already launched. S On 2 Jun 2009, at 15:28, Marcin Hanclik wrote: Hi Scott, In BONDI we have discussed the (has/request)Feature() for some time. http://bondi.omtp.org/1.0/security/BONDI_Architecture_and_Security_v1.0.pdf , section 4.3 A few points for further discussion: 1. feature (at least in BONDI) is an abstract thing, not just one function. So hasFeature() is simply optimized checking procedure. If you check for a feature and discover that it is available, you may/ should/must assume that a set of functions is available. Otherwise, you have to check each function individually and basically you cannot assume that if one functions is available, then the other is as well. 2. requestFeature() adds dynamism to the Website content. Widgets express their dependency statically by feature. http://bondi.omtp.org/1.0/security/BONDI_Architecture_and_Security_Appendices_v1.0.pdf B.2 specifies more details. Thanks. Kind regards, Marcin Marcin Hanclik ACCESS Systems Germany GmbH Tel: +49-208-8290-6452 | Fax: +49-208-8290-6465 Mobile: +49-163-8290-646 E-Mail: marcin.hanc...@access-company.com -Original Message- From: public-webapps-requ...@w3.org [mailto:public-webapps-requ...@w3.org ] On Behalf Of Scott Wilson Sent: Tuesday, June 02, 2009 3:18 PM To: Henri Sivonen Cc: public-webapps Subject: Re: [widgets] What does it mean to have an unavailable API I think in such a case the UA should not be expected to make frob() available, and the Widget should not expect frob() to be present. For example, in the Shindig opensocial runtime, client JS is injected based on the require elements of the gadget. If it isn't declared, it isn't injected, and if you try calling those functions they just aren't there. What this does make less clear for me is in W:AE why you'd ever want to call hasFeature()? S On 2 Jun 2009, at 13:51, Henri Sivonen wrote: Ok. I see what you mean. Widget.hasFeature has slightly different semantics (in widgets, it means did that feature I requested load and become available? Which brings up the issue that it's unclear what it means for an API to have latent support but not having been activated with feature. If a widget UA has an implementation for window.frob() and frob() requires feature activation, what should happen when frob() hasn't been activated with feature? Should there be no function object for frob()? Or should it be there but throw upon calling? Or something else. Please specify this. -- Henri Sivonen hsivo...@iki.fi http://hsivonen.iki.fi/ Access Systems Germany GmbH Essener Strasse 5 | D-46047 Oberhausen HRB 13548 Amtsgericht Duisburg Geschaeftsfuehrer: Michel Piquemal, Tomonori Watanabe, Yusuke Kanda www.access-company.com CONFIDENTIALITY NOTICE This e-mail and any attachments hereto may contain information that is privileged or confidential, and is intended for use only by the individual or entity to which it is addressed. Any disclosure, copying or distribution of the information by anyone else is strictly prohibited. If you have received this document in error, please notify us
RE: [widgets] What does it mean to have an unavailable API
Hi Jonas, requestFeature() is mainly (still debated, though) for websites, i.e. online content where the feature is not present. feature is for packaged widgets only. However this does not seem to be true if the exploited code could simply call requestFeature() first, and then use the feature. Calling requestFeature() does not mean that the security aspects are omitted. The check against the security policy happens when requestFeature() is called. Thanks. Kind regards, Marcin Marcin Hanclik ACCESS Systems Germany GmbH Tel: +49-208-8290-6452 | Fax: +49-208-8290-6465 Mobile: +49-163-8290-646 E-Mail: marcin.hanc...@access-company.com -Original Message- From: Jonas Sicking [mailto:jo...@sicking.cc] Sent: Tuesday, June 02, 2009 7:19 PM To: Marcin Hanclik Cc: Scott Wilson; Henri Sivonen; public-webapps Subject: Re: [widgets] What does it mean to have an unavailable API On Tue, Jun 2, 2009 at 7:28 AM, Marcin Hanclik marcin.hanc...@access-company.com wrote: Hi Scott, In BONDI we have discussed the (has/request)Feature() for some time. http://bondi.omtp.org/1.0/security/BONDI_Architecture_and_Security_v1.0.pdf, section 4.3 A few points for further discussion: 1. feature (at least in BONDI) is an abstract thing, not just one function. So hasFeature() is simply optimized checking procedure. If you check for a feature and discover that it is available, you may/should/must assume that a set of functions is available. Otherwise, you have to check each function individually and basically you cannot assume that if one functions is available, then the other is as well. 2. requestFeature() adds dynamism to the Website content. Widgets express their dependency statically by feature. http://bondi.omtp.org/1.0/security/BONDI_Architecture_and_Security_Appendices_v1.0.pdf B.2 specifies more details. Doesn't the requestFeature() make at least the security benefits of feature moot? In Another thread Marcos stated that one of the benefits of feature was that if a widget gets exploited, the exploited code couldn't get access to any features that the widget hadn't enabled using feature. However this does not seem to be true if the exploited code could simply call requestFeature() first, and then use the feature. / Jonas Access Systems Germany GmbH Essener Strasse 5 | D-46047 Oberhausen HRB 13548 Amtsgericht Duisburg Geschaeftsfuehrer: Michel Piquemal, Tomonori Watanabe, Yusuke Kanda www.access-company.com CONFIDENTIALITY NOTICE This e-mail and any attachments hereto may contain information that is privileged or confidential, and is intended for use only by the individual or entity to which it is addressed. Any disclosure, copying or distribution of the information by anyone else is strictly prohibited. If you have received this document in error, please notify us promptly by responding to this e-mail. Thank you.
RE: [widgets] What does it mean to have an unavailable API
Hi Marcos, requestFeature() from BONDI 1.0 is an asynchronous API that follows API design pattern: http://bondi.omtp.org/1.0/apis/BONDI_Interface_Patterns_v1.0.html#asynchronicity requestFeature() is described in detail in: http://bondi.omtp.org/1.0/security/BONDI_Architecture_and_Security_v1.0.pdf section 4.3.2 A call to the successCallback Function signifies that the request has been satisfied and that the corresponding JavaScript API is immediately available. It means basically that you can directly use the requested API if the request to have it was successful. You do not have to perform any further checks and there is actually a bunch of interfaces that are available, not just a single object. Thanks. Kind regards, Marcin Marcin Hanclik ACCESS Systems Germany GmbH Tel: +49-208-8290-6452 | Fax: +49-208-8290-6465 Mobile: +49-163-8290-646 E-Mail: marcin.hanc...@access-company.com -Original Message- From: marcosscace...@gmail.com [mailto:marcosscace...@gmail.com] On Behalf Of Marcos Caceres Sent: Tuesday, June 02, 2009 7:50 PM To: Jonas Sicking Cc: Marcin Hanclik; Scott Wilson; Henri Sivonen; public-webapps Subject: Re: [widgets] What does it mean to have an unavailable API On Tue, Jun 2, 2009 at 7:19 PM, Jonas Sicking jo...@sicking.cc wrote: On Tue, Jun 2, 2009 at 7:28 AM, Marcin Hanclik marcin.hanc...@access-company.com wrote: Hi Scott, In BONDI we have discussed the (has/request)Feature() for some time. http://bondi.omtp.org/1.0/security/BONDI_Architecture_and_Security_v1.0.pdf, section 4.3 A few points for further discussion: 1. feature (at least in BONDI) is an abstract thing, not just one function. So hasFeature() is simply optimized checking procedure. If you check for a feature and discover that it is available, you may/should/must assume that a set of functions is available. Otherwise, you have to check each function individually and basically you cannot assume that if one functions is available, then the other is as well. 2. requestFeature() adds dynamism to the Website content. Widgets express their dependency statically by feature. http://bondi.omtp.org/1.0/security/BONDI_Architecture_and_Security_Appendices_v1.0.pdf B.2 specifies more details. Doesn't the requestFeature() make at least the security benefits of feature moot? In Another thread Marcos stated that one of the benefits of feature was that if a widget gets exploited, the exploited code couldn't get access to any features that the widget hadn't enabled using feature. However this does not seem to be true if the exploited code could simply call requestFeature() first, and then use the feature. I don't know what the BONDI doc says, but this is certainly not what should happen (unless something changed since I stopped working with Bondi on this). The idea with getFeature, IIRC, is that you first declare a feature, e.g., feature name=foo:bar, and then you can ask for an pointer to it at runtime: script var foobarator = Bondi.getFeature(foo:bar); foobarator.crush().kill().destroy(); var barfoo = Bondi.getFeature(bar:foo); barfoo === underfined; // true /script -- Marcos Caceres http://datadriven.com.au Access Systems Germany GmbH Essener Strasse 5 | D-46047 Oberhausen HRB 13548 Amtsgericht Duisburg Geschaeftsfuehrer: Michel Piquemal, Tomonori Watanabe, Yusuke Kanda www.access-company.com CONFIDENTIALITY NOTICE This e-mail and any attachments hereto may contain information that is privileged or confidential, and is intended for use only by the individual or entity to which it is addressed. Any disclosure, copying or distribution of the information by anyone else is strictly prohibited. If you have received this document in error, please notify us promptly by responding to this e-mail. Thank you.
[widgets] PC LC, general comments
Marcos, all, some more review comments for Widgets 1.0 Packaging and Configuration LC (Working Draft 28 May 2009), this time of a more general nature (not so much L10N-related). /1/ RFC 2119 keyword usage In writing specs, the work split between MAY and SHOULD is sometimes problematic. I tend to use MAY when there is something that is slightly out of line but permissible in some cases, and SHOULD when it is generally a very good idea or almost mandatory to do something, but it can be skipped given enough reasons. This is why I reacted to this statement in section 3.1: A user agent MAY support the [Widgets-DigSig] specification ... And would have written it as: A user agent SHOULD support ... The same goes for section 3.2. I would say: a user agent SHOULD support the its:span element and the its:dir attribute, and MAY support other ITS elements and attributes. Also, the right name for ITS is Internationalization Tag Set (ation vs. ed). 4 Conformance Checker Last sentence in the section: CCs are NOT REQUIRED to display all messages at once. Here, NOT REQUIRED is not valid RFC 2119 keyword usage. Suggest to remove this sentence altogether, and change the preceding sentence to say: The wording and presentation of the advisory messages are implementation-dependent. 5 Zip Archive It would be enough to say: The packaging format for the files of a widget is the Zip archive format as defined in the [ZIP] file format specification. For conformance (last paragraph in section before note) I suggest, for clarity: To conform to this specification, a Zip archive MUST contain one or more file entries and MUST be a valid Zip archive. (c.f MUST NOT be invalid) 5.2 Version of Zip For Zip version 2.0 features, the MAYs should not be marked up as keywords. 8.5 The widget element, definition of width attribute: Which view modes SHOULD honor the value of this attribute is defined in the the [Widgets-Views] specification. This is invalid keyword usage, suggest to replace with: The view modes that honor the value of this attribute are defined in the [Widgets-Views] specification. /2/ UTF-8 encoding So, we still can't mandate the use of UTF-8 as the path encoding? Of course, RECOMMENDED is fairly strong, but I would prefer MUST. As soon as you move out of US-ASCII range, the bytes CP437 and UTF-8 will be different even for the limited number of non-US-ASCII chacters that CP437 can represent. Marcin has already commented on the ABNF of utf8-chars, I'll participate in that discussion if necessary. 5.4 Reserved Characters: suggest to reverse the order of the glyph and character columns. 8.11 The content element, definition of charset attribute: - Despite widespread use, the name charset is not good. A more accurate name would be encoding. - Suggest to replace (a user agent are REQUIRED to support [UTF-8]) with User agents MUST support [UTF-8]. /3/ JPEG icons This may have been beaten to death before, but I wondered why a JPEG file is not allowed as the default icon. /4/ Configuration document It is not currently an error to have a file called 'config.xml' anywhere inside the widget's folder structure. The only one that matters is the one in the root folder. Maybe the CC should warn about the presence of multiple config.xml documents? In 8.2 Proprietary Extensions, first para, last sentence: For the sake of interoperability, extensions to the configuration document are NOT RECOMMENDED. Two problems: 1) NOT RECOMMENDED is not valid keyword usage; 2) it is OK to extend the configuration document because there is a well-defined mechanism that uses namespaces. Suggestion: remove this statement. Version attribute: in the ABNF, doesn't 1*2DIGIT mean that a version number like 123 would be invalid? Especially build numbers are often three or four digits long. Of course, this is only a guideline, but still... Numeric attribute: apparently all numeric attributes are non-negative. Isn't there any use case for negative numbers, ever? Also, non-Western numerals are not acceptable by this definition, but that might not be a showstopper in this case. Keyword attribute: Is the set of allowable characters inherited straight from the XML spec? Is it self-evident that keywords can't contain spaces because it is the keyword list separator? Couldn't comma also be used as a separator? Boolean attribute: it is stated that only true and false are valid values, but that if the value is something else, the default is false. That seems like a contradiction. Are values other than literal true and false supposed to be actual errors, or are they silently coerced into false? (If I accidentally type required=rue it would come out as false...) /5/ Rule for Parsing a Non-negative Integer Couldn't we just refer to some well-established definition, if there is one handy? Seems like this must have been done many times before. And what about those negative numbers, then? Not needed? :-) Hope this helps, Jere @ Nokia
[widgets] Draft Agenda for 4 June 2009 Voice Conference
Below is the draft agenda for the June 4 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 (maximum) 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. Widgets Digital Signature spec a. Agree on candidate exit criteria: http://lists.w3.org/Archives/Public/public-webapps/2009AprJun/ 0700.html b. Proposal to publish Candidate Recommendation c. Dependency on XML Sig 1.1: how far can this spec go, etc. - led by Mike or Thomas 4. Prepare for June 9-11 f2f meeting a. Draft agenda: comments, priorities, etc.: http://www.w3.org/2008/webapps/wiki/ WidgetsLondonJune2009#Agenda_Items b. Open Actions: please address Open actions before the f2f meeting: http://www.w3.org/2008/webapps/track/products/8 5. Access Requests spec http://dev.w3.org/2006/waf/widgets-access/ a. Action 347 - Submit requirements for WAR spec to public-webapps http://www.w3.org/2008/webapps/track/actions/347 http://www.w3.org/2009/05/28-wam-minutes.html#item03 b. Call for Use Cases and Requirements http://lists.w3.org/Archives/Public/public-webapps/2009AprJun/ 0581.html 6. AOB
[widgets] PC Last Call comments, viewmodes, referencing other specs, guarantee of consistency
Hi Marcos, All,
General comment to the below details:
It is possible that some of the referenced specs will change considerably and
may break some ideas from the current PC.
As you know PC is referenced by some other specs (e.g. BONDI).
Could we somehow ensure the stability of the PC references?
Below issues seem to only be symptoms of the problems we may have in the near
future.
It is not only about Views, I think.
Formal view:
http://www.w3.org/Consortium/Process-20010208/tr.html#last-call
says:
Call announcement must:
1. specify the deadline for review comments;
2. identify known dependencies and solicit review from all dependent Working
Groups;
3. solicit public review. Consequently, a Last Call Working Draft must be a
public document.
I am not sure whether the item 3 is satisfied.
MQE is marked as unpublished and we have (in my opinion) stability issues with
the normative references.
1. PC on one hand specifies viewmodes in RelaxNG (non-normatively):
attribute viewmodes {
list {
( application
| floating
| fullscreen
| mini
| all )*
}
}?,
and on the other hand PC directs the reader to another spec (Widgets-Views)
where the said modes are not specified.
2. Parts of this document reproduce text and behavior from the
[HTML5]http://dev.w3.org/2006/waf/widgets/#html5 specification and from the
XBL 2.0 specificationhttp://www.w3.org/TR/xbl/ (as permitted by both
specifications by their copyright statements).
Questions for 1. And 2.:
Does the spec have to reproduce the text from other specs?
Could we have one (maybe a master) definition of the terms, just for
consistency reasons?
3. [Widgets-Views]
Widgets 1.0: Media Query
Extensionshttp://dev.w3.org/2006/waf/widgets-wm/Overview.src.html. A.
Bersvendsen and M. Caceres. Unpublished editors' draft.
Is this the correct reference in terms of the naming (views vs. MQE)?
I think everything a
Marcin Hanclik
ACCESS Systems Germany GmbH
Tel: +49-208-8290-6452 | Fax: +49-208-8290-6465
Mobile: +49-163-8290-646
E-Mail: marcin.hanc...@access-company.com
Access Systems Germany GmbH
Essener Strasse 5 | D-46047 Oberhausen
HRB 13548 Amtsgericht Duisburg
Geschaeftsfuehrer: Michel Piquemal, Tomonori Watanabe, Yusuke Kanda
www.access-company.com
CONFIDENTIALITY NOTICE
This e-mail and any attachments hereto may contain information that is
privileged or confidential, and is intended for use only by the
individual or entity to which it is addressed. Any disclosure, copying or
distribution of the information by anyone else is strictly prohibited.
If you have received this document in error, please notify us promptly by
responding to this e-mail. Thank you.
Re: [widgets] PC LC, general comments
On Wed, Jun 3, 2009 at 12:50 PM, jere.kapy...@nokia.com wrote: Marcos, all, some more review comments for Widgets 1.0 Packaging and Configuration LC (Working Draft 28 May 2009), this time of a more general nature (not so much L10N-related). /1/ RFC 2119 keyword usage In writing specs, the work split between MAY and SHOULD is sometimes problematic. I tend to use MAY when there is something that is slightly out of line but permissible in some cases, and SHOULD when it is generally a very good idea or almost mandatory to do something, but it can be skipped given enough reasons. right. This is why I reacted to this statement in section 3.1: A user agent MAY support the [Widgets-DigSig] specification ... And would have written it as: A user agent SHOULD support ... The point of it being a MAY is that all the user agents are independent. The architecture of each spec is designed to work independently of each other where possible. The same goes for section 3.2. I would say: a user agent SHOULD support the its:span element and the its:dir attribute, and MAY support other ITS elements and attributes. Also, the right name for ITS is Internationalization Tag Set (ation vs. ed). Woops, fixed :) This is now a MAY. 4 Conformance Checker Last sentence in the section: CCs are NOT REQUIRED to display all messages at once. Here, NOT REQUIRED is not valid RFC 2119 keyword usage. Suggest to remove this sentence altogether, and change the preceding sentence to say: The wording and presentation of the advisory messages are implementation-dependent. I changed it to: It is OPTIONAL for a CC to display all messages at once. 5 Zip Archive It would be enough to say: The packaging format for the files of a widget is the Zip archive format as defined in the [ZIP] file format specification. Yes, that is better (I had a bunch of things linking to the various parts of the original statement, but I'll fix that up). For conformance (last paragraph in section before note) I suggest, for clarity: To conform to this specification, a Zip archive MUST contain one or more file entries and MUST be a valid Zip archive. (c.f MUST NOT be invalid) Used your text. 5.2 Version of Zip For Zip version 2.0 features, the MAYs should not be marked up as keywords. fixed. 8.5 The widget element, definition of width attribute: Which view modes SHOULD honor the value of this attribute is defined in the the [Widgets-Views] specification. This is invalid keyword usage, suggest to replace with: The view modes that honor the value of this attribute are defined in the [Widgets-Views] specification. Nice! Fixed for both width and height. /2/ UTF-8 encoding So, we still can't mandate the use of UTF-8 as the path encoding? Of course, RECOMMENDED is fairly strong, but I would prefer MUST. We can, but it would be a waste of time. I don't know any zip implementation that supports this properly. As soon as you move out of US-ASCII range, the bytes CP437 and UTF-8 will be different even for the limited number of non-US-ASCII chacters that CP437 can represent. Right. Marcin has already commented on the ABNF of utf8-chars, I'll participate in that discussion if necessary. I updated the draft by using the UTF-8 ranges defined in the IRI spec (but extended it to cover %x80 and beyond). I also relaxed language tag requirement. 5.4 Reserved Characters: suggest to reverse the order of the glyph and character columns. done. 8.11 The content element, definition of charset attribute: - Despite widespread use, the name charset is not good. A more accurate name would be encoding. - Suggest to replace (a user agent are REQUIRED to support [UTF-8]) with User agents MUST support [UTF-8]. changed globally. /3/ JPEG icons This may have been beaten to death before, but I wondered why a JPEG file is not allowed as the default icon. Oh wwhosss, how did I miss that one!?! In there now! /4/ Configuration document It is not currently an error to have a file called 'config.xml' anywhere inside the widget's folder structure. The only one that matters is the one in the root folder. Maybe the CC should warn about the presence of multiple config.xml documents? I don't think this is relevant, as a config file in a folder has no special meaning. Also, if in the future we migrate to the using multiple config files for localization, then this might not be desirable. Is that ok? In 8.2 Proprietary Extensions, first para, last sentence: For the sake of interoperability, extensions to the configuration document are NOT RECOMMENDED. Two problems: 1) NOT RECOMMENDED is not valid keyword usage; Argh, true. 2) it is OK to extend the configuration document because there is a well-defined mechanism that uses namespaces. Suggestion: remove this statement. Ok, I think it has served it's purpose already :) I've removed it. Version attribute: in the ABNF, doesn't 1*2DIGIT mean that a version
RE: [widgets] PC Last Call comments, viewmodes, referencing other specs, guarantee of consistency
Hi Marcos,
I am not sure whether the item 3 is satisfied.
What do you mean?
For example:
http://www.w3.org/TR/2009/WD-widgets-20090528/#the-widget-element
viewmodes
A keyword list attribute that denotes the view modes supported the widget.
The value SHOULD be one or more of the following valid view modes as defined in
the [Widgets-Views] specification: application, floating, fullscreen, mini, or
all. ...
The question is: which spec is more normative here? PC or non-existing
Widgets-Views?
As a WUA vendor I would like to support all possible values.
As a widget developer I am interesting in knowing all the options I have.
PC will be stable, and the other specs in the widget family will need
to adapt to it.
I take this as your personal guarantee.
I assume, though, that there is or could be some better process to make it
reality.
Marcin, there is only a limited number of editors. We are doing the
best we can to pump out specs. But there is only so many hours in the
day.
I can help you. Shall I answer formally to:
http://lists.w3.org/Archives/Public/public-webapps/2009AprJun/0503.html
I'm going to assume a is awesome :)
I am sorry for this. My problem.
Marcin Hanclik
ACCESS Systems Germany GmbH
Tel: +49-208-8290-6452 | Fax: +49-208-8290-6465
Mobile: +49-163-8290-646
E-Mail: marcin.hanc...@access-company.com
-Original Message-
From: marcosscace...@gmail.com [mailto:marcosscace...@gmail.com] On Behalf Of
Marcos Caceres
Sent: Wednesday, June 03, 2009 5:38 PM
To: Marcin Hanclik
Cc: public-webapps
Subject: Re: [widgets] PC Last Call comments, viewmodes, referencing other
specs, guarantee of consistency
On Wed, Jun 3, 2009 at 4:51 PM, Marcin Hanclik
marcin.hanc...@access-company.com wrote:
Hi Marcos, All,
General comment to the below details:
It is possible that some of the referenced specs will change considerably
and may break some ideas from the current PC.
PC will be stable, and the other specs in the widget family will need
to adapt to it.
As you know PC is referenced by some other specs (e.g. BONDI).
Could we somehow ensure the stability of the PC references?
Only the ones in the Widget Family of Specs, but not others. However,
PC does not reference many other working drafts in any significant
way.
Below issues seem to only be symptoms of the problems we may have in the
near future.
It is not only about Views, I think.
Formal view:
http://www.w3.org/Consortium/Process-20010208/tr.html#last-call
says:
“Call announcement must:
specify the deadline for review comments;
identify known dependencies and solicit review from all dependent Working
Groups;
solicit public review. Consequently, a Last Call Working Draft must be a
public document.”
I am not sure whether the item 3 is satisfied.
What do you mean?
MQE is marked as unpublished and we have (in my opinion) stability issues
with the normative references.
1. PC on one hand specifies viewmodes in RelaxNG (non-normatively):
attribute viewmodes {
list {
( application
| floating
| fullscreen
| mini
| all )*
}
}?,
and on the other hand PC directs the reader to another spec
(“Widgets-Views”) where the said modes are not specified.
Marcin, there is only a limited number of editors. We are doing the
best we can to pump out specs. But there is only so many hours in the
day.
2. “Parts of this document reproduce text and behavior from the
[HTML5] specification and from the XBL 2.0 specification (as permitted by
both specifications by their copyright statements).”
Questions for 1. And 2.:
Does the spec have to reproduce the text from other specs?
No.
Could we have one (maybe a “master”) definition of the terms, just for
consistency reasons?
Maybe, but that is just more work. That is the reason I am editor of
all the specs, so I can keep consistency across all of them. So,
unless I die in a unforeseen accident, I think we should be ok.
3. [Widgets-Views]
Widgets 1.0: Media Query Extensions. A. Bersvendsen and M. Caceres.
Unpublished editors' draft.
Is this the correct reference in terms of the naming (views vs. MQE)?
It's ok for now... we will sort out that mess in the next few weeks.
It's really nothing to worry about.
I think everything a
I'm going to assume a is awesome :)
--
Marcos Caceres
http://datadriven.com.au
Access Systems Germany GmbH
Essener Strasse 5 | D-46047 Oberhausen
HRB 13548 Amtsgericht Duisburg
Geschaeftsfuehrer: Michel Piquemal, Tomonori Watanabe, Yusuke Kanda
www.access-company.com
CONFIDENTIALITY NOTICE
This e-mail and any attachments hereto may contain information that is
privileged or confidential, and is intended for use only by the
individual or entity to which it is addressed. Any disclosure, copying or
distribution of the information by anyone else is strictly prohibited.
If you have received this document in error,
Re: [widgets] PC Last Call comments, viewmodes, referencing other specs, guarantee of consistency
On 6/3/09 5:54 PM, Marcin Hanclik wrote:
Hi Marcos,
I am not sure whether the item 3 is satisfied.
What do you mean?
For example:
http://www.w3.org/TR/2009/WD-widgets-20090528/#the-widget-element
viewmodes
A keyword list attribute that denotes the view modes supported the widget. The
value SHOULD be one or more of the following valid view modes as defined in the
[Widgets-Views] specification: application, floating, fullscreen, mini, or all.
...
The question is: which spec is more normative here? PC or non-existing
Widgets-Views?
As a WUA vendor I would like to support all possible values.
As a widget developer I am interesting in knowing all the options I have.
I understand. Like I said, we are working as quickly as we can. There is
nothing we can do about this. The values are settled on; but they need
to be spec'ed properly.
PC will be stable, and the other specs in the widget family will need
to adapt to it.
I take this as your personal guarantee.
You got it.
I assume, though, that there is or could be some better process to make it
reality.
Yes, our process is a bit screwy but we get by.
Marcin, there is only a limited number of editors. We are doing the
best we can to pump out specs. But there is only so many hours in the
day.
I can help you. Shall I answer formally to:
http://lists.w3.org/Archives/Public/public-webapps/2009AprJun/0503.html
We already have editors for the specs; it's just that the editors are
caught up over editing. What we need is reviewers. The more reviews we
get, the quicker we move. If you want to really help, keep reviewing
what we already have. Your review of PC has been very helpful.
I'm going to assume a is awesome :)
I am sorry for this. My problem.
Marcin Hanclik
ACCESS Systems Germany GmbH
Tel: +49-208-8290-6452 | Fax: +49-208-8290-6465
Mobile: +49-163-8290-646
E-Mail: marcin.hanc...@access-company.com
-Original Message-
From: marcosscace...@gmail.com [mailto:marcosscace...@gmail.com] On Behalf Of
Marcos Caceres
Sent: Wednesday, June 03, 2009 5:38 PM
To: Marcin Hanclik
Cc: public-webapps
Subject: Re: [widgets] PC Last Call comments, viewmodes, referencing other
specs, guarantee of consistency
On Wed, Jun 3, 2009 at 4:51 PM, Marcin Hanclik
marcin.hanc...@access-company.com wrote:
Hi Marcos, All,
General comment to the below details:
It is possible that some of the referenced specs will change considerably
and may break some ideas from the current PC.
PC will be stable, and the other specs in the widget family will need
to adapt to it.
As you know PC is referenced by some other specs (e.g. BONDI).
Could we somehow ensure the stability of the PC references?
Only the ones in the Widget Family of Specs, but not others. However,
PC does not reference many other working drafts in any significant
way.
Below issues seem to only be symptoms of the problems we may have in the
near future.
It is not only about Views, I think.
Formal view:
http://www.w3.org/Consortium/Process-20010208/tr.html#last-call
says:
“Call announcement must:
specify the deadline for review comments;
identify known dependencies and solicit review from all dependent Working
Groups;
solicit public review. Consequently, a Last Call Working Draft must be a
public document.”
I am not sure whether the item 3 is satisfied.
What do you mean?
MQE is marked as unpublished and we have (in my opinion) stability issues
with the normative references.
1. PC on one hand specifies viewmodes in RelaxNG (non-normatively):
attribute viewmodes {
list {
( application
| floating
| fullscreen
| mini
| all )*
}
}?,
and on the other hand PC directs the reader to another spec
(“Widgets-Views”) where the said modes are not specified.
Marcin, there is only a limited number of editors. We are doing the
best we can to pump out specs. But there is only so many hours in the
day.
2. “Parts of this document reproduce text and behavior from the
[HTML5] specification and from the XBL 2.0 specification (as permitted by
both specifications by their copyright statements).”
Questions for 1. And 2.:
Does the spec have to reproduce the text from other specs?
No.
Could we have one (maybe a “master”) definition of the terms, just for
consistency reasons?
Maybe, but that is just more work. That is the reason I am editor of
all the specs, so I can keep consistency across all of them. So,
unless I die in a unforeseen accident, I think we should be ok.
3. [Widgets-Views]
Widgets 1.0: Media Query Extensions. A. Bersvendsen and M. Caceres.
Unpublished editors' draft.
Is this the correct reference in terms of the naming (views vs. MQE)?
It's ok for now... we will sort out that mess in the next few weeks.
It's really nothing to worry about.
I think everything a
I'm going to assume a is awesome :)
--
Marcos Caceres
http://datadriven.com.au
Re: [widgets] PC Last Call comments, viewmodes, referencing other specs, guarantee of consistency
On 3 Jun 2009, at 16:38, Marcos Caceres wrote: Maybe, but that is just more work. That is the reason I am editor of all the specs, so I can keep consistency across all of them. So, unless I die in a unforeseen accident, I think we should be ok. And a very good job you're doing too - so please take care when crossing busy roads! ;-) S smime.p7s Description: S/MIME cryptographic signature
Re: [widgets] PC Last Call comments, viewmodes, referencing other specs, guarantee of consistency
Marcin, Marcos, All,
On Jun 3, 2009, at 12:14 PM, ext Marcos Caceres wrote:
On 6/3/09 5:54 PM, Marcin Hanclik wrote:
Hi Marcos,
I am not sure whether the item 3 is satisfied.
What do you mean?
For example:
http://www.w3.org/TR/2009/WD-widgets-20090528/#the-widget-element
viewmodes
A keyword list attribute that denotes the view modes
supported the widget. The value SHOULD be one or more of the
following valid view modes as defined in the [Widgets-Views]
specification: application, floating, fullscreen, mini, or all. ...
The question is: which spec is more normative here? PC or non-
existing Widgets-Views?
As a WUA vendor I would like to support all possible values.
As a widget developer I am interesting in knowing all the options
I have.
I understand. Like I said, we are working as quickly as we can.
There is
nothing we can do about this. The values are settled on; but they need
to be spec'ed properly.
Perhaps one of the things that adds some confusion here is the PC's
[Widgets-Views] reference is to the Widgets 1.0: Media Query
Extension spec whereas I believe the plan of record is for that
reference to point to a completely different document (for which
there currently is no Editor's Draft), probably titled something like
Widgets 1.0: {Window,View} Modes.
As all of us that have attended the weekly calls over the last few
months know, the priorities have been PC, DigSig and AE, and Marcos
in particular has done an exceptional job to move those specs forward.
Marcin, there is only a limited number of editors. We are doing the
best we can to pump out specs. But there is only so many hours
in the
day.
I can help you. Shall I answer formally to:
http://lists.w3.org/Archives/Public/public-webapps/2009AprJun/
0503.html
We already have editors for the specs; it's just that the editors are
caught up over editing. What we need is reviewers. The more reviews we
get, the quicker we move. If you want to really help, keep reviewing
what we already have. Your review of PC has been very helpful.
Robin and Marcos have agreed to be Editors of the View Modes spec. As
always, what we need is specific inputs. Marcin, if you have some
inputs for the View Modes spec, please send them to the list. Note
too that last week, Bryan agreed to provide input for the View Modes
spec [1].
-Regards, Art Barstow
[1] http://www.w3.org/2009/05/28-wam-minutes.html#item06
Origin enables XSS to escalate to XSRF (was: security issue with XMLHttpRequest API compatibility)
On Thu, Apr 9, 2009 at 8:48 AM, Bil Corry b...@corry.biz wrote: My point is that a robust Origin moves us closer to better security controls, perhaps not all the way, but certainly much closer than CORS-Origin gets us. I admit that I haven't followed in detail the various origin proposals (cors, html5, ietf (withdrawn?)). I am glad to see that people want an origin proposal with good security properties. However, I fear all the current proposals amplify one of the browser's worst security hazards -- abuse of ambient authority creating confused deputy hazards. The current browser same origin policy already has plenty of these problems http://waterken.sourceforge.net/aclsdont/. To be concrete, pages contain content -- whether mashups, gadgets, or simple libraries -- whose authorship does not correspond to the browser's notion of origin. As Crock said in his w2sp keynote http://w2spconf.com/2009/presentations/keynote-slides.pdf, A mashup is a self inflicted cross site script. The problem isn't the mixing of scripts representing different interests. The problem is that all scripts that execute on a page are implicitly allowed to exercise all the authority that this browser associates with that page's origin. How do these origin proposals amplify this hazard? The main (only?) motivation for the origin header is to enable servers to make allow/deny access decisions on cross-origin requests based on the presented value of the origin header. This means that a script running on a page from origin A can now make a cross-origin request to a server at origin B and exercise the authority that this server associates with origin A. If some of these origin proposals still allow the browser to present the credentials (e.g., cookies) that browser associates with B, then, despite protestations to the contrary, we have also failed to address existing XSRF dangers. Three proposals I've seen in these threads, if combined and extended, point towards a solution. 1) The thread starting at http://www.mail-archive.com/public-webapps@w3.org/msg02791.html and ending in: On Tue, Apr 14, 2009 at 5:34 AM, Arthur Barstow art.bars...@nokia.com wrote: On Apr 14, 2009, at 6:33 AM, ext Thomas Roessler wrote: So, to pick up on this discussion again -- I don't think we've had a useful conclusion whether or not the client-side JavaScript code ought to explicitly enable cross-site requests (as Tyler suggests, and as IE implements in XDR) or not. All things considered, any thoughts? I tend to think that when adding new semantics, it generally makes sense to add new syntax to support those semantics and in this case that it would be better to err on the side of caution even if the mechanism chosen isn't particularly friendly to the app developer. 2) In the IETF origin proposal but absent from the cors proposal, a browser (user agent) must send an origin header for cross origin requests, but may send Origin: null, i.e., identify only that this is a cross-origin request without identifying what the requesting origin is. 3) In some of these proposals, the browser may, should, or must (apologies for losing track) not present its credentials for B when making a cross origin request from A to B. (Note that the definition of credential used in these discussions never mentions the new origin header despite expectation that servers will use this header to make access control decisions. This is confused.) Being a language geek, I wouldn't describe Tyler's proposal as new syntax but rather distinct API. That nit aside, I agree with Arthur that these are adequate reasons to adopt this API change. But I care about this for a bigger reason. It points the way to a general solution to the ambient authority problems currently associated with browser origin policies. In Tyler's proposal, there are different constructors for making XMLHttpRequest objects. All such constructors would create XMLHttpRequest objects with the same API but with different security policies. * The policy associated with the current constructor name would continue to refuse to make cross-origin requests. * If, as I expect, there are people here who are attached to currently proposed policies, despite the ambient authority dangers, a different constructor could provide XMLHttpRequest objects with that behavior. (And future noscript-like browser extensions can disable it.) * When the script initially occupying a page wishes to deny its own ambient authority to later scripts loaded onto that page, it can arrange that only our third constructor is available to them. This third constructor creates XMLHttpRequest objects that never transmit ambient credential information (e.g. cookies) and that adds Origin: null as an extra header to *all* requests, even those back to the page's own origin, in order to warn servers to treat all these requests as cross origin requests with no identified origin. This is the initial script's way of saying Content
