- From: Marcin Hanclik <Marcin.Hanclik@access-company.com>
- Date: Wed, 30 Sep 2009 13:20:39 +0200
- To: "marcosc@opera.com" <marcosc@opera.com>
- CC: "public-webapps@w3.org" <public-webapps@w3.org>
Hi Marcos, >>> 5.4.2#2.4.1 >>> ... apply the rule for dealing with an invalid Zip archive ... >>> And >>> "In the event that an implementation encounters an invalid Zip archive ... >>> In the case the UA is a CC, it must inform the author that the Zip archive >>is an invalid Zip archive." From P&C. >>> >>> Do not play well together. >>> The problem is with the WUA and not with the widget, so the correct >>information should be provided to the user. >> >>Sorry. I don't understand the problem, can you elaborate? Are you >>saying that all UAs (not just CCs) must inform the end-user of the >>error? 7.4.2 says: "If the user agent cannot write to the storage area (e.g., because it ran out of disk space, or the space quota was exceeded, etc.), apply the rule for dealing with an invalid Zip archive specified in the [Widgets-Packaging] specification." The problem is that "the user agent cannot write to the storage area" and the action is related to invalid Zip archive. It is possible that the UA will inform the user that the Zip archive is invalid as part of the rule (probably added by the implementers). And then the end-user would get notified e.g. that "Widget is corrupted", whereas simply the WUA does not have enough quota. >>> @href from <license> and license, >> >>What is the use case? Similar to description, nothing specific. I think the rule could be to map the elements and attributes from config.xml to DOM. The spec could then probably be shorter and easily extensible. >>> icons >> >>What is the use case? Also, these may be changing dynamically so it >>makes things a mess. As above, just map what we have in config.xml. >>> The above requirements seem contradicting and not prepared for handling the >>security policy. >> >>Which "security policy"? Any, specifically the one planned for DAP. At present we have WARP LCWD as a sample of the security policy. Thanks, 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.hanclik@access-company.com -----Original Message----- From: marcosscaceres@gmail.com [mailto:marcosscaceres@gmail.com] On Behalf Of Marcos Caceres Sent: Wednesday, September 23, 2009 6:10 PM To: Marcin Hanclik Cc: public-webapps@w3.org Subject: Re: [A&E] Last Call comments (1) 2009/9/15 Marcin Hanclik <Marcin.Hanclik@access-company.com>: > The below comments refer to: > Widgets 1.0: The widget Interface > Editor's Draft 14 September 2009 > > General: > Replace "can" with "may" in the whole document. I've used can deliberately throughout the document where statements of fact are made. To use may would result in a conformance clause where one is not needed. > 2. > Feature > Why to repeat the definition from P&C? People complain about having to jump from spec to spec. Makes the document easier to read. > Getting / Setting > Refer to HTML5 for those definitions? No, they are defined in WebStorage but I stole them (muahaha!) :) I only reference other specs where something that affects conformance/behavior is said. > Viewport > [1] says that scrollbars are part of the rendering area > (I do not claim that it is fully correct, I assume scrollbars are a discussion point, specifically in the context of DHTML where they could appear and vanish depending on the dynamic content). > My proposal is to make this definition non-final. > > All definitions: > Could we have a document with the definitions for all specifications from the family? That could be possible, but some definitions are inline - better to leave them where they are and just follow the anchors in the document. > 3. > achived -> achieved Fixed. > 4. > Again about the definitions: > Could we have a common definition of the user agent, decoupled from the specs? > (e.g. UA in P&C is an implementation, here it is a software implementation) Yes, we have talked about this but just haven't got around to doing it. I personally don't think we need an overarching definition, however. The more modular these specs are, the better IMO. We try to make it pretty clear what the dependencies for each UA are. > 4.2 > a read-only item is an item in a storage area cannot be ... > should be > a read-only item is an item in a storage area that cannot be ... Fixed. > 5. > Why aren't the following attributes available on the widget interface? > @viewmodes from <widget>, That's your spec :) Add it as supplemental attribute to the widget interface. > @short from <name>, I would not mind adding this one, maybe calling it widget.shortname. > @href from <license> and license, What is the use case? > icons What is the use case? Also, these may be changing dynamically so it makes things a mess. I think we should create and Icon API at some point in the near future (leverage HTML5 cross-doc communication), but we should not add anything poorly specified now. > 5. > It preferences(via the preferences attribute). > Unclear. Yikes, changed it to: "The interface also allows authors to access persistently-stored preferences (via the preferences attribute)." > 5. > A user agent should to impose ... > Should be > A user agent should impose ... I've deleted that assertion (Artb pointed out that it is an untestable weasel assertion). > 5. > ... global object context of the widget's start file. > What about: > ... global object context of the document loaded from widget's start file. > ??? I'm working on a better definition for this with Robin. > 5. > In > ... global object context of the widget's start file. > And > A user agent whose start file implements HTML5's Window interface ... > The "start file"s refer to 2 different locations. I'm going to rewrite all this. Will let you know as soon as it is done. > 5.4 > How to handle multiple instances of the same widget? > As far as I remember it was to be moved to WURIv2, but it seems important in the context of preferences. No, it's not important. They are bound to the origin of a widget as defined in WURI, and the origin of a widget is universally unique. Hence, preferences are unique and not shared. > 5.4 > Storage interface: > The A&E specification should not add interpretation to the WebStorage with regard to the exceptions thrown. It would be better to improve the WebStorage specification. > Hixie was the one who said we need to define it here. There is no notion of a read-only items in Web Storage. We can ask Hixie again, but I doubt he will pay us any attention (besides, I agree with him. It should be spec'd in our spec... no need to bloat WebStorage with widget-only stuff). > Specifically the NO_MODIFICATION_ALLOWER_ERR shall be presented in WebIDL on Storage interface based on "raises" keyword of WebIDL. > That would be nice. I don't know any WebIDL. Do you want to write a supplemental IDL declaration for us to include in the spec? We can live without it, but would be nice to have (makes the spec easier to understand). > 5.4.1 > onClick -> onclick Fixed (though I don't think case matters in HTML5, the parser still works it out) > 5.4.2#3 > ... make the preferences attribute a pointer that storage area. > Should be > ... make the preferences attribute a pointer to that storage area. Fixed. > 5.4.2#2.4.1 > ... apply the rule for dealing with an invalid Zip archive ... > And > "In the event that an implementation encounters an invalid Zip archive ... > In the case the UA is a CC, it must inform the author that the Zip archive is an invalid Zip archive." From P&C. > > Do not play well together. > The problem is with the WUA and not with the widget, so the correct information should be provided to the user. Sorry. I don't understand the problem, can you elaborate? Are you saying that all UAs (not just CCs) must inform the end-user of the error? > The problem > 5.5 > ... should open the provided iri ... > What does opening of the IRI mean? > Maybe this would work (IRI handler could be defined anyway) : > > ... should handle the provided iri ... I like it. Used your text. > 5.5 > ... it is otherwise rejected by the user agent (e.g., because of security policy or user prompting), or iri is not a valid IRI, then the user agent must act as if the method had not been invoked. > > The user agent should inform the end-user when a request to handle the IRI via the openURL() method has failed. Ok, I agree. I will specify this and let you know once it is done. > The above requirements seem contradicting and not prepared for handling the security policy. Which "security policy"? > a) acting as if the method had not been invoked (a MUST) and informing the end user (a SHOULD) may not work well together. > b) it should be possible for the UA to reject the call to openURL, and then the exception or error shall be thrown, so that the script could catch it and inform the user. > I suggest leaving the WebIDL for openURL to DAP. So you suggest we take this method out of this spec? > 5.5 > Last sentence seems to be lost in action. FIxed. Added "invoked". (there is stupid bug in my editor which keeps deleting lines for no reason! :( ) > [1] http://dev.w3.org/2006/waf/widgets-vm/vm-mediafeature.src.html -- 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.
Received on Wednesday, 30 September 2009 11:21:35 UTC