Re: [Widget URI] Internationalization, widget IRI?
On Thu, Sep 3, 2009 at 1:32 PM, Marcin Hanclikmarcin.hanc...@access-company.com wrote: Hi Robin, Thanks for your comments. I believe the terminology could be clarified once the IRI/URI issue from PC gets solved in I18N, hopefully together with HREF and all related stuff. +1 for simplification. I'm still not understanding the problem in the PC spec. Let me try to walk through a simple widget. Marcin, pretend I'm 9 years old and explain the problem to me in the most simplest of terms possible (i.e., don't cite me URI/IRI spec stuff because all that stuff makes no sense, just talk to me about bytes... I'm one those smarty 9 year-olds, who knows about bytes, but as a consequence gets pushed around by bullies...:)). USE CASE 1 1. I have a widget called foo.wgt. The widget contains 2 files: mañana.html and config.xml. 2. The file names of both files are encoded in the zip archive as UTF-8 (explicitly marked as such by the presence of a flag). 3. In the config doc, which is encoded in iso-8859-1, it says: content src=mañana.html/ 4. The UA reads the value of src attribute and converts it to UTF-8. 5. The UA matches the string that represents the value of src to the mañana.html file entry. 6. done? USE CASE 2 1. I have a widget called foo.wgt. The widget contains 2 files: mañana.html and config.xml. 2. The file names of both files are encoded in the zip archive as CP-437 (explicitly marked as such). 2.1 The UA maps all the files names in the zip archive to UTF-8 equivalents. 3. In the config doc, which is encoded in iso-8859-1, it says: content src=mañana.html/ 4. The UA reads the value of the src attribute and converts it to UTF-8. 5. The UA matches the string that represents the value of src to the mañana.html file entry. 6. done? -- Marcos Caceres http://datadriven.com.au
Re: CfC: to publish a new Working Draft of Web Storage spec; deadline 7 September
On Aug 31, 2009, at 2:01 PM, Barstow Art (Nokia-CIC/Boston) wrote: This is a Call for Consensus (CfC) to publish a new WD of the Web Storage spec: http://dev.w3.org/html5/webstorage/ As with all of our CfCs, positive response is preferred and encouraged and silence will be assumed to be assent. The deadline for comments is September 7. Nokia this publication. -Regards, Art Barstow
Re: CfC: to publish the First Public Working Draft of Web Database spec; deadline 7 September
On Aug 31, 2009, at 2:01 PM, Barstow Art (Nokia-CIC/Boston) wrote: This is a Call for Consensus (CfC) to publish the First Public Working Draft (FPWD) of the Web Database spec: http://dev.w3.org/html5/webdatabase/ Note that at one point in time, the Web Database spec's functionality was included in the Web Storage spec. As with all of our CfCs, positive response is preferred and encouraged and silence will be assumed to be assent. The deadline for comments is September 7. We support this publication and look forward to comments on the current model as well as counter-proposals. -Regards, Art Barstow
Re: PFWG comments on Widgets 1.0: Packaging and Configuration Last Call (late, very late)
On Thu, Aug 27, 2009 at 5:51 PM, Michael Coopercoo...@w3.org wrote: This is a review of Widgets 1.0: Packaging and Configuration http://www.w3.org/TR/2009/WD-widgets-20090528/, the Last Call Working Draft. These comments are submitted on behalf of the Protocols and Formats Working Group and are focused on accessibility to people with disabilities. We apologize for sending these comments late, after the document has gone to Candidate Recommendation. We approved sending these comments on 17 June 2009 http://www.w3.org/2009/06/17-pf-minutes#item04, but failed to track that they actually got sent. Since the document progressed to Candidate Recommendation before we discovered the error, we understand that you may not be able to accommodate most of these comments. However, we believe it is important to put the comments on the record nevertheless. You may be able to address some of them as editorial items on the Candidate Recommendation, and the remainder could inform requirements for a future version. We do not, however, object to this version of the document proceeding to Recommendation as is, since the failure to send comments on time is ours. Fantastic. 1) Text alternatives An object as complex as a packaged widget will certainly need a text alternative or label for accessibility. The possibility for this is provided with the name element (including the short version) and the description element. However, these are optional features of the configuration document. The name element should be required; in other words, there should be 1 or more, not 0 or more. Unfortunately, it's too late to change this. The description element could remain optional. In addition to enforcing this, conformance checkers should also raise a warning if there is not a name element provided for each localization, at least for every major language (may not be a huge issue for regional variants). This seems reasonable. As we don't yet have anyone who has opted in to implement the CC requirements, I'm wondering if we can add this. We are debating if we should move all the conformance requirements for a CC's out of PC to a new spec. If we do that, we would certainly add this to that spec. The name element for the widget would also fulfill the role of a text alternative / label for the icon. In particular, the short name might serve as a good label, while the longer name serve as a text alternative for accessibility purposes. The description would also be something it would be important to expose to assistive technologies. This handling of icons should be clearly spelled out. Because of the way we have architectured the PC user agent, the above would not apply to PC. We have removed requirements that the PC user agent should expose icons, license, etc. and will put those into a separate Widget User Agent spec. To put it simply, the PC UA is just an application the processes Zip files and configuration documents - that is it, does not expose or do anything else: running the widget, exposing icons, etc. is left up to other consumers of the PC specification. That new spec would also be a good place to deal with the requirement above (i.e., make it more clear what the relationship is between icons, name, and description from an accessibility POV. I would very much like to collaborate with PFWG on this, but that is future work at this point). 2) Width and height attributes The width and height attributes only allow pixel values. Pixel values are notoriously problematic across device and user contexts. Furthermore it is odd that these attributes are limited to pixels when they are explicitly disallowed when a pixel-based raster graphic is used. If the author is using a vector format, why would they then restrict it to a specific pixel value? The pixel value represents the minimum value at which an icon would be used for a given context. A vector graphic might only look good at, for instance, resolutions larger than 100 pixels (because of anti-aliasing, which makes things look blurry and and text illegible). So, below 100 pixels, the author might prefer to use a raster graphic - particularly for really small icons (e.g., 16X16). Users with disabilities frequently need to customize size presentation. While user agents can be instructed to ignore pixel values or apply a multiplier to them, the results are often sub-optimal. It is better to allow the author to define more adaptable length units. Measurements such as inches and centimetres adapt better to various display devices then pixels; ems and percent adapt better to specific display contexts. While in a packaged widget, the context needed to resolve ems and percent units may not always be present, it often will be. Therefore, we suggest that the entire set of CSS length units be supported by these attributes. Ok, for now, we have limited this to CSS pixels. In future versions, we could allow any CSS length unit. I've added this
ISSUE-101 (Marcin Hanclik): Event's generation [ViewModes]
ISSUE-101 (Marcin Hanclik): Event's generation [ViewModes] http://www.w3.org/2008/webapps/track/issues/101 Raised by: Marcin Hanclik On product: ViewModes Should the events [1] be triggered before or after the actual values change? (implies naming change vs. changed) [1] http://dev.w3.org/2006/waf/widgets-vm/vm-interfaces.src.html
ISSUE-100 (Marcin Hanclik): Event's bubbling and cancelation [ViewModes]
ISSUE-100 (Marcin Hanclik): Event's bubbling and cancelation [ViewModes] http://www.w3.org/2008/webapps/track/issues/100 Raised by: Marcin Hanclik On product: ViewModes Should the view modes interfaces' [1] events bubble and be cancelable? http://lists.w3.org/Archives/Public/public-webapps/2009JulSep/0230.html [1] http://dev.w3.org/2006/waf/widgets-vm/vm-interfaces.src.html
Re: [widgets] Seeking comments on Last Call WD of Widgets: APIs and Events spec; deadline 15 Sept 2009
On Fri, Aug 21, 2009 at 1:10 PM, Scott Wilsonscott.bradley.wil...@gmail.com wrote: Metadata Attributes and the Storage Area I don't think its clear from the spec if metadata attributes are within the scope of widget.preferences and must be stored in the same storage area. ok, I can try to clarify this. But I'm not sure where this is confusing. E.g. Does widget.preferences.getItem(name) == widget.name? if not, then why does a script calling widget.preferences.setItem(name, blah) need the UA to throw an exception? Hmm. That is certainly not what was implied. They are totally separate things. Can you point me to the offending text in the spec? Some options: 1. metadata attributes must be treated as equivalent to preferences, and in fact should be able to be accessed in the same manner; No, this is not what we want. 2. metadata attributes are not the same as preferences, and their storage should not conflict with preferences. Therefore preferences with the same keys as metadata attribute names are fine. Yes, this is what is what we have been intending to spec. Again, what part of the spec is broken and implying otherwise? 3. metadata attributes should not be made accessible using widget.preferences, but must be treated as being stored in the same storage area, and potentially have conflicting keys; therefore preferences with the same keys as metadata attribute names are disallowed. No, certainly not. They are separate things. (We currently implement using option 1, but would be happy with option 2. I don't think option 3 has much merit) Agreed. I think we have consensus in the WG that 2 is what we want and what should have been in the spec all along. Read-only Metadata Attributes For read-only attributes, I note that there is no actual conformance statement. I suggest adding a nice broad one in 6.1, to allow more UAs to reach conformance: A User Agent SHOULD take reasonable steps to prevent author scripts from modifying Metadata Attributes. Where it is not practical for a User Agent to prevent an author script setting or clearing a Metadata Attribute during runtime, the User Agent MUST NOT persist any such modifications for further instantiations of the Widget. From my understanding is that private members can be used in Javascript: http://www.crockford.com/javascript/private.html Hence, it would be possible for a javascript implementation of the spec to comply. Having said that, as the spec says, the interfaces are defined in terms of IDL which already defines readonly: The attribute is read only if the readonly terminal is used in the definition. An object that implements the interface on which a read only attribute is defined will not allow assignment to that attribute. It is language binding specific whether assignment is simply disallowed by the language, ignored or an exception is thrown. To include the text you suggested would be a tautology (and possibly lead to further confusion, as it redefines readonly). For a script-based implementation, I would follow this document: http://ejohn.org/blog/javascript-getters-and-setters/ The fact that JS still allows you to delete properties is not the fault of the implementation (it's a consequence of the platform on which the implementation is done). The implementation should still be able to conform (read pass the test suite) even though such a thing can happen. So a web browser implementing the spec can declare the attributes in the Window and make them read-only as it controls the environment, and Wookie can just not save any changes beyond the scope of the current browser session. Right. Section 5.1 and syntactic sugar == Section 5.1, para 4 reads: Upon invocation of the setItem() or removeItem() method by an author script on a protected key, user agent must throw a NO_MODIFICATION_ALLOWED_ERRexception. The NO_MODIFICATION_ALLOWED_ERR is defined in the [DOM3Core] specification. OK, this is fine, we can implement this. However, what about: widget.preferences.blah = new value; // where blah is a read-only key We really don't have any way to prevent this happening or throwing an exception. Luckily for us the conformance statement above doesn't mention it, which means we don't have to! Hmm... However I don't think this was the intention - it just shows one of the problems with the syntactic sugar interpretation of WebStorage. For any UA other than a browser, you really don't get the option to protect exposed javascript properties. Are you absolutely sure about this? No fancy closures, or using Crockfords' methods will help here? I suggest changing the example in 6.4.2 to use getItem(), and adding a note re: alternative syntax. Personally I'd rather exclude them for the sake of interoperability. If not, 5.1 para 4 6.4 para 4 need changing to cover semantically-equivalent operations using alternative
Re: [widgets] Widgets URI scheme... it's baaaack!
On Tue, May 26, 2009 at 5:38 PM, Jean-Claude Dufourdjean-claude.dufo...@telecom-paristech.fr wrote: Marcos, Mark, all, I am picking up the discussion where Cyril left it some months ago. I have read this thread, the Oct 08 one, the proposed URI scheme spec, even skimmed through the wam minutes. I still am leaning towards Mark's position. It seems to me that the URI scheme is not needed, or if needed, the reasons have not yet been shown. I am trying to reformulate the situation: 0- the author needs a way to point to resources within the widget package 1- the URI scheme will never be used by the author (written by Marcos), the author will use relative URIs for resources within the widget. 2- the browser will have to resolve the relative URI to an absolute URI because of the DOM spec, hence a possible vulnerability by divulging private information (e.g. actual name of current user in file: URI example of Apple Dashboard widgets) to scripts running in the widget. 3- Marcos seems to be deducing from 2- that a URI scheme must be defined for mandatory internal use in all widget UAs to guarantee that this vulnerability does not exist. 3- does not follow logically from 2-. Mandating the implementation in the widget UA of a URI resolution that does not divulge private information to the widget scripts is sufficient to ensure that the vulnerability mentioned in 2- does not happen. The proposed URI scheme could be suggested as an option, but not more. My understanding is that 3- mandates a particular URI scheme which will never be used by the author and will never be exchanged between two implementations. My past standardization experience is that things which will never be used by the author and will never be exchanged between two implementations should not be standardized at all. Are there other predicates for the need for standardisation ? No. Just to stop implementers from using file://. I guess then it doesn't matter. All the URI scheme should be is an informative note that implementers should be allowed to use if they want. Implementers should be able to use whatever scheme they want so long as the end result is indistinguishable from what would be obtained from using the widget URI scheme. Marcos mentions the widget V2 spec and extensibility as one reason for adopting the proposed URI scheme. I would like to understand how V2 and extensibility could make the URI scheme either seen by the author or exchanged between implementations, or make its absence otherwise imperil implementations. Personally, I wish implementations would use http as a scheme AND as a protocol. That is, the widget user agent behave as a web server when serving any/all content to itself. -- Marcos Caceres http://datadriven.com.au
Re: [WARP] Last Call comments (1)
Hi Marcin, I tried to respond to this email, but in all honesty, I can't follow your line of argumentation. Maybe you can list your main points as a list (sorry, I'm a bit simple)... From what I got, I agree that WARP is over reaching: It does not address the requirements it lists from the Widgets 1.0: Requirements document. Otherwise, I'll just leave it to Robin to respond. I've made some notes on the proposed changes. On Thu, Aug 27, 2009 at 8:06 PM, Marcin Hanclikmarcin.hanc...@access-company.com wrote: PROPOSED CHANGES Given the semantic similarities (or equivalence) between: access uri=http://example.org; subdomains=true/ and e.g.: feature name=http://www.w3.org/widgetfeatures/networkaccess/http; required=false param name=uri value=http://example.org/ param name=subdomains value=true/ /feature What you did in 192 characters, the access element does in 52. That is the point of the access element: to make these kind of annoying declarations easy to write. I propose the following: 1. Change the name of the specification to Widgets 1.0: Network Access Feature and focus on per-URI-scheme definition of the syntax dependencies and functionality. Examples: a) The following feature could replace the generic network access (proposed in the LCWD as * for @uri attribute): feature name=http://www.w3.org/widgetfeatures/networkaccess; required=true / b) The following features could define the http and https access feature name=http://www.w3.org/widgetfeatures/networkaccess/http; required=false param name=uri value=http://example.org/ param name=subdomains value=true/ param name=ports value=80, 8080/ /feature feature name=http://www.w3.org/widgetfeatures/networkaccess/https; required=true param name=uri value=https://example.org/ param name=subdomains value=false/ param name=interface value=XMLHttpRequest/ !-- port defaults to 443 -- /feature c) The following feature could define access to SMS feature: feature name=http://www.w3.org/widgetfeatures/networkaccess/sms; required=true param name=uri value=sms:+16177166200/ /feature feature name=http://www.w3.org/widgetfeatures/networkaccess/sms; required=true param name=countrycallingcodes value=1,48,49,34/ /feature 2. Rewrite parts of the specification - specifically section 3, while keeping its majority as is - to adhere to the syntax of the feature and param elements as outlined above. 3. Refrain from specifying the default policy; remove the word security from the specification (since this is to be handled in DAP). 4. Focus in the specification text only on declarative aspects of the intention of the author of the widget, leaving e.g. prompting aspects for DAP. I.e. assuming that the network access is conditional, what are the implications for the widget's code and author in case the network access is not present or its presence is dynamic? (e.g. provide a definition of the event mechanism). 5. In order to be able to define the IRI for network access feature, another document should probably be prepared that would also define the namespace for the further feature definitions (e.g. http://www.w3.org/widgetfeatures/). 6. Focus in the specification only on http and https. subdomains attribute / value of the parameter is valid mainly for this protocol family (also including e.g. rtsp, ftp etc.). Other schemes, like sms, tel, mms (there is no RFC for some) have their own specificities, e.g. country calling/dialing codes, shortcodes. Thanks. Kind regards, Marcin [1] http://www.w3.org/TR/2009/WD-widgets-access-20090804/ [2] http://lists.w3.org/Archives/Public/public-webapps/2009JulSep/0290.html [3] http://lists.w3.org/Archives/Public/public-webapps/2009JulSep/0294.html [4] http://www.w3.org/TR/widgets [5] http://www.w3.org/TR/widgets/#the-feature-element [6] http://www.w3.org/TR/widgets/#the-widget-family-of-specifications [7] http://www.w3.org/TR/2009/WD-widgets-access-20090804/#introduction [8] http://www.w3.org/TR/2009/WD-widgets-access-20090804/#definitions [9] http://www.w3.org/TR/2009/WD-widgets-access-20090804/#design-goals-and-requirements [10] http://www.w3.org/TR/widgets-reqs/#default-security-policy [11] http://www.w3.org/TR/widgets-reqs/#security-declarations [12] http://www.w3.org/2009/06/09-wam-minutes.html [13] http://www.w3.org/2009/05/DeviceAPICharter [14] http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-August/022264.html 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
Re: [widgets] Widgets URI scheme... it's baaaack!
On Wed, Sep 2, 2009 at 4:33 PM, Robin Berjonro...@berjon.com wrote: On May 23, 2009, at 19:21 , Mark Baker wrote: Right. That's the same point Arve made. I don't see a problem with it. Sure, a widget will be able to discover an implementation detail of its widget container - the base URI - but it's still up to the container to permit or deny access to other resources from that widget when asked to dereference it, whether the widget discovered the URI via a mechanism such as the one you describe, or even if it simply guessed it. Calling it an implementation detail doesn't make it one. Say I have a script in which I need to identify resources that I'm currently using from within the widget. Since I don't want to have to care how the designers linked them in, I'll use their absolute URIs to compare them. If implementation A returns http://magic-widget-host.local/dahut.svg;, and implementation B file:///special-widget-mount/dahut.svg, and C gives me made-up:/dahut.svg we don't exactly have interoperability. And here is where the fun starts. How do we reconcile the above without a new scheme? This gets more interesting once you bring the localisation mechanism from P+C into play, whereby the Zip relative path and the relative URI are different when you have multilingual content. Exactly. -- Marcos Caceres http://datadriven.com.au
Re: Web Notifications, do we need a new spec?
Hi Jeremy, On Fri, Aug 7, 2009 at 11:21 AM, Marcos Caceresmarc...@opera.com wrote: Jeremy Orlow wrote: On Fri, Jul 31, 2009 at 1:52 AM, Marcos Caceres marc...@opera.com mailto:marc...@opera.com wrote: Keeping in line with the design goals to enable Widget-related technologies to be used on the Web, I'm wondering if we should spawn a separate specification for notifications? We could use the current text in the AE [1] as the basis, which is based heavily on what was originally in HTML5 (or just take the old HTML5 text, create the new spec, add the hooks for Widgets). Although notifications have been taken out of HTML5, rumblings that they may need reviving occurred recently on the WHAT-WG list: http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-March/019113.html There was a lot of talk about notifications in this more recent thread as well: http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-July/thread.html#21421 (The thread is long and talks about a lot of things besides notifications, but I think there are some key insights in that thread about the requirements for notifications.) I'll take a look and see what I can extract from the discussion. As a followup to the above, the following code was submitted by Google to WebKit to support notifications: https://bugs.webkit.org/show_bug.cgi?id=25463 So, the question is: do we need a new/separate spec? One that covers both Web and Widgets? I think we do need to start thinking about specing this out. Off the top of my head, it seems like the requirements for the web and widgets will be pretty similar. I agree. Lets take notifications out of Widgets API. I think the next action should be to formally start capturing these requirements. If you have time to list some requirements you guys have, that would be great. Just following up on notifications. Are you still interested in perusing this? Can you guys provide any resources to help get this work started? Kind regards, Marcos -- Marcos Caceres http://datadriven.com.au
Re: Web Notifications, do we need a new spec?
We are in the middle of implementing in WebKit and in Chromium, so yes we are still interested in pursuing. John Gregg (johnnyg@) has been leading the effort from our end. Beyond an implementation that people can experiment with, what sort of resources are you looking for? 2009/9/4 Marcos Caceres marc...@opera.com Hi Jeremy, On Fri, Aug 7, 2009 at 11:21 AM, Marcos Caceresmarc...@opera.com wrote: Jeremy Orlow wrote: On Fri, Jul 31, 2009 at 1:52 AM, Marcos Caceres marc...@opera.com mailto:marc...@opera.com wrote: Keeping in line with the design goals to enable Widget-related technologies to be used on the Web, I'm wondering if we should spawn a separate specification for notifications? We could use the current text in the AE [1] as the basis, which is based heavily on what was originally in HTML5 (or just take the old HTML5 text, create the new spec, add the hooks for Widgets). Although notifications have been taken out of HTML5, rumblings that they may need reviving occurred recently on the WHAT-WG list: http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-March/019113.html There was a lot of talk about notifications in this more recent thread as well: http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-July/thread.html#21421 (The thread is long and talks about a lot of things besides notifications, but I think there are some key insights in that thread about the requirements for notifications.) I'll take a look and see what I can extract from the discussion. As a followup to the above, the following code was submitted by Google to WebKit to support notifications: https://bugs.webkit.org/show_bug.cgi?id=25463 So, the question is: do we need a new/separate spec? One that covers both Web and Widgets? I think we do need to start thinking about specing this out. Off the top of my head, it seems like the requirements for the web and widgets will be pretty similar. I agree. Lets take notifications out of Widgets API. I think the next action should be to formally start capturing these requirements. If you have time to list some requirements you guys have, that would be great. Just following up on notifications. Are you still interested in perusing this? Can you guys provide any resources to help get this work started? Kind regards, Marcos -- Marcos Caceres http://datadriven.com.au
Re: Web Notifications, do we need a new spec?
Ian Fette (イアンフェッティ) wrote: We are in the middle of implementing in WebKit and in Chromium, so yes we are still interested in pursuing. John Gregg (johnnyg@) has been leading the effort from our end. Beyond an implementation that people can experiment with, what sort of resources are you looking for? Basically, a spec editor. We need to formally gather the requirements and just start writing. I was personally hoping to do this, but I don't have the cycles or experience in this area (which is why I'm asking you guys if you can help me out). Kind regards, Marcos
Re: [widgets] Seeking comments on Last Call WD of Widgets: APIs and Events spec; deadline 15 Sept 2009
On 4 Sep 2009, at 15:46, Marcos Caceres wrote: On Fri, Aug 21, 2009 at 1:10 PM, Scott Wilsonscott.bradley.wil...@gmail.com wrote: Metadata Attributes and the Storage Area I don't think its clear from the spec if metadata attributes are within the scope of widget.preferences and must be stored in the same storage area. ok, I can try to clarify this. But I'm not sure where this is confusing. ... Hmm. That is certainly not what was implied. They are totally separate things. Can you point me to the offending text in the spec? It arises I think because Storage Area is defined just before the section on metadata attributes, without it explicitly stating this is only used for storing preferences, with the possible interpretation that this is how a UA has to store all widget attributes. However that could just be me - I'll get some other people less familiar with the spec to read it and see if they make the same misinterpretation. Agreed. I think we have consensus in the WG that 2 is what we want and what should have been in the spec all along. Great, I'm happy with that too, just need to figure a way of making it unambiguous in the text. Read-only Metadata Attributes From my understanding is that private members can be used in Javascript: http://www.crockford.com/javascript/private.html Hence, it would be possible for a javascript implementation of the spec to comply. Thanks for the link, I hadn't found anything as clear as this before - I'll investigate this over the weekend and report back - it looks hopeful! Having said that, as the spec says, the interfaces are defined in terms of IDL which already defines readonly: The attribute is read only if the readonly terminal is used in the definition. An object that implements the interface on which a read only attribute is defined will not allow assignment to that attribute. It is language binding specific whether assignment is simply disallowed by the language, ignored or an exception is thrown. To include the text you suggested would be a tautology (and possibly lead to further confusion, as it redefines readonly). For a script-based implementation, I would follow this document: http://ejohn.org/blog/javascript-getters-and-setters/ The fact that JS still allows you to delete properties is not the fault of the implementation (it's a consequence of the platform on which the implementation is done). The implementation should still be able to conform (read pass the test suite) even though such a thing can happen. So a web browser implementing the spec can declare the attributes in the Window and make them read-only as it controls the environment, and Wookie can just not save any changes beyond the scope of the current browser session. Right. Thats great - OK I'm happy with that for the conformance issue. Section 5.1 and syntactic sugar == Section 5.1, para 4 reads: Upon invocation of the setItem() or removeItem() method by an author script on a protected key, user agent must throw a NO_MODIFICATION_ALLOWED_ERRexception. The NO_MODIFICATION_ALLOWED_ERR is defined in the [DOM3Core] specification. OK, this is fine, we can implement this. However, what about: widget.preferences.blah = new value; // where blah is a read- only key We really don't have any way to prevent this happening or throwing an exception. Luckily for us the conformance statement above doesn't mention it, which means we don't have to! Hmm... However I don't think this was the intention - it just shows one of the problems with the syntactic sugar interpretation of WebStorage. For any UA other than a browser, you really don't get the option to protect exposed javascript properties. Are you absolutely sure about this? No fancy closures, or using Crockfords' methods will help here? I'll check it out and see - fingers crossed. I suggest changing the example in 6.4.2 to use getItem(), and adding a note re: alternative syntax. Personally I'd rather exclude them for the sake of interoperability. If not, 5.1 para 4 6.4 para 4 need changing to cover semantically- equivalent operations using alternative syntaxes; however unless the conformance requirement is reworded as per my suggestion above for read-only metadata attributes, we probably have to give up any hope of ever conforming to the spec :-( Nah! we will work it out :) :-D -- Marcos Caceres http://datadriven.com.au smime.p7s Description: S/MIME cryptographic signature
[widgets] Apache Social and Widgets Meetup at ApacheCon US, Nov 2009
Hi everyone, There is going to be a meetup at ApacheCon US in November on the area of widgets and related technologies: http://wiki.apache.org/apachecon/SocialAndWidgetsMeetup This is an informal event for people interested the Shindig (OpenSocial), Wookie (W3C Widgets), and SocialSite projects currently in the Apache incubator. More details on ApacheCon US can be found here: http://us.apachecon.com/c/acus2009/ S smime.p7s Description: S/MIME cryptographic signature
[web databases] SQLStatementErrorCallback
Hi, When talking about statement error callbacks (point #6, section 4.3.2), the spec says: 1. If the error callback returns false, then move on to the next statement, if any, or onto the next overall step otherwise. 2. Otherwise, the error callback did not return false, or there was no error callback. Jump to the last step in the overall steps. What should happen if the callback doesn't return anything (undefined)? Should we jump to the transaction error callback? Can/should we clarify this in the spec too? Thanks, Dumi
Re: CfC: to publish the First Public Working Draft of Web Database spec; deadline 7 September
Although formally, this is an FPWD, in reality this is the third FPWD for this content already. While implementable, Oracle is concerned about two aspects of this draft that have never changed materially since the original publication of the said content in HTML5 WDs: 1. Complex programming model that will make usage prone to making more mistakes than usual for database programming 2. Inadequate effort by the editor to ascertain the suitability of this spec to be implemented independently by multiple parties We agree with Jonas and Laxmi that this is neither a great direction to pursue nor is FPWD itself going to bring about much progress. Nevertheless, we, too, support publication of the WebDatabase draft as FPWD. We are also very pleased to announce that following up on our previous strawman proposal [1], we have drafted a new Database API [2] that does not rely on SQL or SQLite. It is still in a relatively early state and will undergo some more changes before we pursue wider publication. However, we welcome any and all feedback on our draft proposal. Nikunj [1] http://www.w3.org/mid/f480f60a-5dae-4b73-922a-93ed401cf...@oracle.com [2] http://dev.w3.org/2006/webapi/WebSimpleDatabase/ On Sep 1, 2009, at 4:36 PM, Jonas Sicking wrote: I support a FPWD since I'm all for drafts of any kind being published. However, I'm still unconvinced that this draft is heading the right way for the web. My concern is two-fold: 1. It doesn't define enough to allow multiple interoperable implementations. This is because the SQL dialect is not defined. 2. SQL doesn't seem very web-friendly. For example the ability to store serializable JS objects and index on a property of that JS object seems hard to fit with SQL. The problem is even greater when the two are combined. Once the SQL dialect is defined, it's quite possible that UAs won't be able to use a SQL library like sqlite, but instead have to more or less build their own SQL implementation. This makes the cost extremely high, and the result not something that even that closely matches what developers want. / Jonas On Mon, Aug 31, 2009 at 3:01 PM, Arthur Barstowart.bars...@nokia.com wrote: This is a Call for Consensus (CfC) to publish the First Public Working Draft (FPWD) of the Web Database spec: http://dev.w3.org/html5/webdatabase/ Note that at one point in time, the Web Database spec's functionality was included in the Web Storage spec. As with all of our CfCs, positive response is preferred and encouraged and silence will be assumed to be assent. The deadline for comments is September 7. -Regards, Art Barstow Nikunj http://o-micron.blogspot.com
[WebSimpleDatabase] New spec, editor's draft available
I have published the first draft of the WebSimpleDatabase API, which is based on B-tree databases [1]. Here's a link to the draft: http://dev.w3.org/2006/webapi/WebSimpleDatabase/ Abstract: This document defines APIs for storing and retreving ordered key-value pairs in a transactional database. I would request feedback that we can incorporate before publication as a working draft. Please note that certain items are purposely under- specified at the moment. I want to gauge the potential interest in this direction and evolve it to meet the needs of the WG. Nikunj http://o-micron.blogspot.com [1] http://www.w3.org/mid/f480f60a-5dae-4b73-922a-93ed401cf...@oracle.com
Re: [WebSimpleDatabase] New spec, editor's draft available
Try this link instead...http://dev.w3.org/2006/webapi/WebSimpleDatabase/ Nikunj's link actually points to http://dev.w3.org/2006/webapi/DataCache/ which is also interesting, but seemingly not what was intended. @Nikunj, I have not yet read thru your draft in detail, but will do so. In principle, I agree with the notion of a standard that does not depend on a particular sql dialect (or an assumed sql dialect) to reap the rewards of structured storage, query, and retrieval. As I said, I haven't read it thru yet... have you addressed full text indexing and search in some form? And if not, that would be a feature request. http://dev.w3.org/2006/webapi/WebSimpleDatabase/ On Fri, Sep 4, 2009 at 1:45 PM, Nikunj R. Mehta nikunj.me...@oracle.comwrote: I have published the first draft of the WebSimpleDatabase API, which is based on B-tree databases [1]. Here's a link to the draft: http://dev.w3.org/2006/webapi/WebSimpleDatabase/http://dev.w3.org/2006/webapi/DataCache/ Abstract: This document defines APIs for storing and retreving ordered key-value pairs in a transactional database. I would request feedback that we can incorporate before publication as a working draft. Please note that certain items are purposely under-specified at the moment. I want to gauge the potential interest in this direction and evolve it to meet the needs of the WG. Nikunj http://o-micron.blogspot.com [1] http://www.w3.org/mid/f480f60a-5dae-4b73-922a-93ed401cf...@oracle.com
Re: [WebSimpleDatabase] New spec, editor's draft available
On Sep 4, 2009, at 7:47 PM, Michael Nordman wrote: Try this link instead... http://dev.w3.org/2006/webapi/WebSimpleDatabase/ Nikunj's link actually points to http://dev.w3.org/2006/webapi/DataCache/ which is also interesting, but seemingly not what was intended. Sorry about this problem. Got tripped by the mail editor there. @Nikunj, I have not yet read thru your draft in detail, but will do so. Look forward to the feedback. In principle, I agree with the notion of a standard that does not depend on a particular sql dialect (or an assumed sql dialect) to reap the rewards of structured storage, query, and retrieval. The intention is to enable a far richer ecosystem of independent implementations. Plus to take advantage of the ECMAScript environment and avoid marshalling between result sets and JavaScript objects. As I said, I haven't read it thru yet... have you addressed full text indexing and search in some form? And if not, that would be a feature request. I am aware of full-text. If someone is willing to contribute resources, I would be glad to work in this feature. On Fri, Sep 4, 2009 at 1:45 PM, Nikunj R. Mehta nikunj.me...@oracle.com wrote: I have published the first draft of the WebSimpleDatabase API, which is based on B-tree databases [1]. Here's a link to the draft: http://dev.w3.org/2006/webapi/WebSimpleDatabase/ Abstract: This document defines APIs for storing and retreving ordered key-value pairs in a transactional database. I would request feedback that we can incorporate before publication as a working draft. Please note that certain items are purposely under-specified at the moment. I want to gauge the potential interest in this direction and evolve it to meet the needs of the WG. Nikunj http://o-micron.blogspot.com [1] http://www.w3.org/mid/f480f60a-5dae-4b73-922a-93ed401cf...@oracle.com Nikunj http://o-micron.blogspot.com
