Re: Widget Test Cases Creation Event - September 21st-23rd, Düsseldorf
Hello all, Le lundi 13 juillet 2009 à 11:57 +0200, Breitschwerdt, Christian, VF-Group a écrit : More information regarding registration, etc to follow shortly via W3C staff/WG chairs. If you are interested in attending that event, please register at: http://www.w3.org/2002/09/wbs/1/widget-test/ The form has indications on the IPR aspect of the event as well. Thanks, Dom
Re: Points of order on this WG
On Thu, 25 Jun 2009, Maciej Stachowiak wrote: On Jun 24, 2009, at 11:35 PM, Ian Hickson wrote: [...] (if anything, I think we should split Web Storage into two further specs [...] [...] I would prefer to see SQL Storage split out of the rest of Web Storage. We seem to have rough consensus and strong multilateral implementor interest on LocalStorage and SessionStorage, and they should be allowed to move forward on the standards track quickly. SQL Storage remains contentious, and only Apple and Google have shown strong implementor interest so far. And it has no technical tie to the other storage drafts. Done. http://dev.w3.org/html5/webstorage/ http://dev.w3.org/html5/webdatabase/ I'll probably not ask for Web Database to go to last call in October (unlike the rest of the specs I'm working on), so that we can add the SQL definition before last call (which I plan to do either Q4 this year or early next year). -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: Widgets PAG seeks feedback on Widget Updates spec
Marcos Caceres a écrit : From the spec ...an author can request that a widget asynchronously check if a widget has been updated [(i.e., that a new version of the widget package is available online)] via the widget.update() method, defined in the Widgets-API specification. This strategy also relies on the author having declared a update element in the widget configuration document, as it makes use of the URI to potentially retrieve an UDD and relay whether an update is available back to the instantiated Widget. ***Actually performing the update is left to the discretion of the widget user agent.*** JCD: this standards trick works if your aim is to have a patent on the highlighted point be judged as non-essential. There are a few points to check to ensure non-essentiality: - the language of the standard makes the feature a MAY (seems to be the case); - no test case uses the feature (should be easy too). However, if the implementations consistently implement the feature, they will infringe the patent and will get a call from the patent holder. It seems to me that this feature may end up as consistently implemented. There would then be a good case for the WG to spend some time on devising a proper workaround. Anyone sharing my opinion that the widget update feature will be consistenly implemented (even if optional) ? Best regards JC -- JC Dufourd Groupe Multimedia/Multimedia Group Traitement du Signal et Images/Signal and Image Processing Télécom ParisTech, 46 rue Barrault, 75 013 Paris, France
Window Modes todo
Hi, I just went through the WM ED and here are the things to do that I gathered (the list may not be exhaustive). Input and help is welcome, feel free to flag what you'd like to volunteer for. - The Abstract needs to be rewritten, it's not entirely easy to understand what it describes. - The SotD need to be written (in preparation of FPWD). - The active editors need to agree on what they'll use to edit/ generate the spec — I'm guess Anolis/Bert Bos. That'll give us a ToC. - The Relevant Inputs section needs to go. - The Introduction is really only the first paragraph, and it needs to be expanded and have references. The rest are definitions which need their own subsection. - The table of window modes should be moved to the MQ section, and the descriptions merged. This places Conformance Requirements right after the Introduction (which is fine — it should be before anything normative). - A clarification of what is meant by feature would help. The widget mode is also referred to but lacks any description. - The scripting interfaces need some love to make them linked, and make sure they are proper WebIDL (notably they could use the implements keyword). They require a lot of documentation to be written. - I think that the MediaFeatureList could be a sequenceCSSStyleDeclaration nowadays. - I forget the original reasoning: is it useful that the event initialisers have canBubbleArg and cancelableArg since presumably no matter what parameter is passed they won't bubble and won't be cancellable? - Acknowledgements need to be written. - References need to be written. - Some examples would be nice (but that's not needed for FPWD). -- Robin Berjon - http://berjon.com/ Feel like hiring me? Go to http://robineko.com/
Re: Widgets PAG seeks feedback on Widget Updates spec
On Wed, Jul 15, 2009 at 1:54 PM, Jean-Claude Dufourdjean-claude.dufo...@telecom-paristech.fr wrote: Marcos Caceres a écrit : From the spec ...an author can request that a widget asynchronously check if a widget has been updated [(i.e., that a new version of the widget package is available online)] via the widget.update() method, defined in the Widgets-API specification. This strategy also relies on the author having declared a update element in the widget configuration document, as it makes use of the URI to potentially retrieve an UDD and relay whether an update is available back to the instantiated Widget. **Actually performing the update is left to the discretion of the widget user agent.** JCD: this standards trick works if your aim is to have a patent on the highlighted point be judged as non-essential. There are a few points to check to ensure non-essentiality: - the language of the standard makes the feature a MAY (seems to be the case); - no test case uses the feature (should be easy too). However, if the implementations consistently implement the feature, they will infringe the patent and will get a call from the patent holder. It seems to me that this feature may end up as consistently implemented. There would then be a good case for the WG to spend some time on devising a proper workaround. Anyone sharing my opinion that the widget update feature will be consistenly implemented (even if optional) ? widget.update() will be dropped from the spec. It serves no useful purpose. Kind regards, Marcos -- Marcos Caceres http://datadriven.com.au
Re: Widgets PAG seeks feedback on Widget Updates spec
Dear Jean-Claude, On Jul 15, 2009, at 13:54 , Jean-Claude Dufourd wrote: Marcos Caceres a écrit : From the spec ...an author can request that a widget asynchronously check if a widget has been updated [(i.e., that a new version of the widget package is available online)] via the widget.update() method, defined in the Widgets-API specification. This strategy also relies on the author having declared a update element in the widget configuration document, as it makes use of the URI to potentially retrieve an UDD and relay whether an update is available back to the instantiated Widget. **Actually performing the update is left to the discretion of the widget user agent.** JCD: this standards trick works if your aim is to have a patent on the highlighted point be judged as non-essential. It's not a trick, but more importantly you're answering the beginning of a thread that has now moved on to entirely different conclusions. There are a few points to check to ensure non-essentiality: - the language of the standard makes the feature a MAY (seems to be the case); But as you know variability in specification through optional features leads directly to a marked lack of interoperability. Therefore using a MAY here would be bad. Since anyway it was never the intent that an update occur when this method is called, and since an optional feature is by and large useless, this entire method has been dropped. This makes the point moot. - no test case uses the feature (should be easy too). Test cases are orthogonal since they are not normative. However, if the implementations consistently implement the feature, they will infringe the patent and will get a call from the patent holder. People are, of course, always free to infringe on any patent they wish. All we care about is that it is possible to implement in a sensible manner and without infringing. Given that we're dropping a feature that could look like self-updating but wasn't, this is a minor concern. It seems to me that this feature may end up as consistently implemented. If it is it won't be because of us since we've concluded that it's of little use and dropped it from the specification! There would then be a good case for the WG to spend some time on devising a proper workaround. Anyone sharing my opinion that the widget update feature will be consistenly implemented (even if optional) ? You seem to be mixing up Widget Updates and the update() method, is that the case? Also, the PAG has convened several times already and should produce its output in a timely manner. So yes the PAG has looked at the problem from a variety of angles (on which I won't comment since its operation is member-only) and when its conclusions are published they will be announced here. -- Robin Berjon - http://berjon.com/ Feel like hiring me? Go to http://robineko.com/
Web Storage Spec as PDF
Hey folks, I have been trying to get a hold of Web Storage Specification as PDF (http://www.w3.org/TR/webstorage/).Can you please help me find PDF for web storage spec? Multiple other points about the same aspect: - It was also difficult for me to find this URL as all the internet talks about Web Storage API as part of HTML5 and http://www.w3.org/TR/html5/ does not talk about it and neither has references to the web storage :(. - I did find the HTML5 Spec as PDFhttp://www.whatwg.org/specs/web-apps/current-work/html5-a4.pdf, and this does not talk about web storage details. - The web storage URL given above says that it is automatically generated from HTML5! All in all I am totally confused on how Web Storage is tied to HTML5 when there is no interlinking anywhere? Thanks, Laxmi
Re: Web Storage Spec as PDF
On Wed, Jul 15, 2009 at 2:13 PM, Laxmi Narsimha Rao Orugantilaxmi.oruga...@microsoft.com wrote: Hey folks, I have been trying to get a hold of Web Storage Specification as PDF (http://www.w3.org/TR/webstorage/). Can you please help me find PDF for web storage spec? There is no PDF. Multiple other points about the same aspect: - It was also difficult for me to find this URL as all the internet talks about Web Storage API as part of HTML5 and Yes, this changed about a month ago. It was ripped out from the spec - two specs are available now: http://dev.w3.org/html5/webstorage/ http://dev.w3.org/html5/webdatabase/ http://www.w3.org/TR/html5/ does not talk about it and neither has references to the web storage L. - I did find the HTML5 Spec as PDF, and this does not talk about web storage details. They are technically unrelated to HTML5 and should be viewed as orthogonal (though terminology from HTML5 is used). - The web storage URL given above says that it is automatically generated from HTML5! All in all I am totally confused on how Web Storage is tied to HTML5 when there is no interlinking anywhere? It doesn't, they are orthogonal. HTML5 UA, however, may implement web storage. -- Marcos Caceres http://datadriven.com.au
Re: Widgets PAG seeks feedback on Widget Updates spec
Dear Robin, Thanks for your email. Robin Berjon a écrit : There would then be a good case for the WG to spend some time on devising a proper workaround. Anyone sharing my opinion that the widget update feature will be consistenly implemented (even if optional) ? You seem to be mixing up Widget Updates and the update() method, is that the case? JCD: I understood the widget.update() method being discussed to be the scripted version of the Widget Updates mechanism. Please tell me if I am wrong. The current draft seems to still say that. And I am really not sure that a script-triggered version of the update mechanism can be discarded off-hand. Best regards JC PS: test sequences may be informative, but their content defines what is tested for normative behavior, so if a feature is tested in a sequence, it will appear normative to lawyers, even if the text of the spec says otherwise. -- JC Dufourd Groupe Multimedia/Multimedia Group Traitement du Signal et Images/Signal and Image Processing Télécom ParisTech, 46 rue Barrault, 75 013 Paris, France
Re: Widgets PAG seeks feedback on Widget Updates spec
On 7/15/09 5:56 PM, Jean-Claude Dufourd wrote: Dear Robin, Thanks for your email. Robin Berjon a écrit : There would then be a good case for the WG to spend some time on devising a proper workaround. Anyone sharing my opinion that the widget update feature will be consistenly implemented (even if optional) ? You seem to be mixing up Widget Updates and the update() method, is that the case? JCD: I understood the widget.update() method being discussed to be the scripted version of the Widget Updates mechanism. No. Read the spec. It says it's just a way of checking if an update is available (by asking the UA to check) and _not_ a way for a widget to update itself. Apples and oranges, as they say! (no pun intended) Please tell me if I am wrong. The current draft seems to still say that. You are wrong. The current draft does not specify anything normative about the behavior of widget.update(). And I am really not sure that a script-triggered version of the update There has _NEVER_ been a script-triggered version of the update or any such functionality specified by the Working Group. To imply otherwise is misleading. mechanism can be discarded off-hand. Yes it can: I discarded it from the spec. The point is moot. The issue has been resolved. Widget.update() does not exist (and has absolutely nothing to do with the PAG or whatever: widget.update was deemed useless by the Working Group long ago. We've just been too busy to publish a new draft without widget.update()). So, please stop bringing up this closed issue. As the Working Group awaits the findings of the PAG on how to proceed with Widget Updates, I find it inappropriate that you continue to discuss this matter here. Once the PAG findings are made public, and the WG has a chance to respond and act, then, if you have concerns, raise them here. Kind regards, Marcos
Re: Points of order on this WG
The abstract still states: [[ This specification defines two APIs for persistent data storage in Web clients: one for accessing key-value pair data and another for accessing structured data. ]] Nikunj http://o-micron.blogspot.com On Jul 15, 2009, at 3:56 AM, Ian Hickson wrote: On Thu, 25 Jun 2009, Maciej Stachowiak wrote: On Jun 24, 2009, at 11:35 PM, Ian Hickson wrote: [...] (if anything, I think we should split Web Storage into two further specs [...] [...] I would prefer to see SQL Storage split out of the rest of Web Storage. We seem to have rough consensus and strong multilateral implementor interest on LocalStorage and SessionStorage, and they should be allowed to move forward on the standards track quickly. SQL Storage remains contentious, and only Apple and Google have shown strong implementor interest so far. And it has no technical tie to the other storage drafts. Done. http://dev.w3.org/html5/webstorage/ http://dev.w3.org/html5/webdatabase/ I'll probably not ask for Web Database to go to last call in October (unlike the rest of the specs I'm working on), so that we can add the SQL definition before last call (which I plan to do either Q4 this year or early next year). -- Ian Hickson U+1047E) \._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _ \ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'-- (,_..'`-.;.'
Re: Do we need to rename the Origin header?
Ian Hickson wrote on 7/14/2009 6:37 PM: On Tue, 14 Jul 2009, Bil Corry wrote: Ian Hickson wrote on 7/14/2009 12:49 AM: (Trimmed cc list to avoid cross-posting.) On Thu, 25 Jun 2009, Bil Corry wrote: Thanks for the clarification. Will there be some mechanism within HTML5 to denote links that are privacy-sensitive versus those that are not? I'm imagining that by default, links to external resources would be considered private unless denoted as public (non-private?). I have no plans to add such a feature at this time, but I suppose if Sec-From becomes popular, we could add it at some future point, sure. The Sec-From draft relies on the adopter to define what constitutes privacy-sensitive -- will you be adding this definition to HTML5? HTML5 will say whatever Adam tells me it should say once the draft is stable. Given that identical requests may or may not be privacy-sensitive based entirely on context[1], and given that only the site itself understands the context, and given that HTML5 will not provide a way for the author to denote the context, we're left with Adam's default definition which may or may not be appropriate for any given request. We should revisit this once Adam has defined privacy-sensitive. - Bil [1] Jonas Sicking does an excellent job of explaining the thorny issue of privacy-sensitive and context in this post: http://www.mail-archive.com/public-webapps@w3.org/msg04001.html
Re: Do we need to rename the Origin header?
On Wed, 15 Jul 2009, Bil Corry wrote: Ian Hickson wrote on 7/14/2009 6:37 PM: On Tue, 14 Jul 2009, Bil Corry wrote: Ian Hickson wrote on 7/14/2009 12:49 AM: (Trimmed cc list to avoid cross-posting.) On Thu, 25 Jun 2009, Bil Corry wrote: Thanks for the clarification. Will there be some mechanism within HTML5 to denote links that are privacy-sensitive versus those that are not? I'm imagining that by default, links to external resources would be considered private unless denoted as public (non-private?). I have no plans to add such a feature at this time, but I suppose if Sec-From becomes popular, we could add it at some future point, sure. The Sec-From draft relies on the adopter to define what constitutes privacy-sensitive -- will you be adding this definition to HTML5? HTML5 will say whatever Adam tells me it should say once the draft is stable. Given that identical requests may or may not be privacy-sensitive based entirely on context[1], and given that only the site itself understands the context, and given that HTML5 will not provide a way for the author to denote the context, we're left with Adam's default definition which may or may not be appropriate for any given request. We should revisit this once Adam has defined privacy-sensitive. I expect that what Adam will tell me to do is to make everything in HTML5 privacy-sensitive except GETs. I expect XHR GETs will not be. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: Window Modes todo
Robin Berjon: - I forget the original reasoning: is it useful that the event initialisers have canBubbleArg and cancelableArg since presumably no matter what parameter is passed they won't bubble and won't be cancellable? Shouldn’t canBubbleArg and cancelableArg be honoured when user script creates and dispatches an event? Even if events created by the implementation are always non-bubbling and non-cancellable. -- Cameron McCormack ≝ http://mcc.id.au/
