Re: Widget Test Cases Creation Event -> September 21st-23rd, Düsseldorf

[Dominique Hazael-Massieux]

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

[Ian Hickson]

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

[Jean-Claude Dufourd]

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

[Robin Berjon]

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  
sequence 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

[Marcos Caceres]

On Wed, Jul 15, 2009 at 1:54 PM, 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.
> 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

[Robin Berjon]

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

[Laxmi Narsimha Rao Oruganti]

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 
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

[Marcos Caceres]

On Wed, Jul 15, 2009 at 2:13 PM, Laxmi Narsimha Rao
Oruganti 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] conformance requirements review

[Dominique Hazael-Massieux]

Le lundi 13 juillet 2009 à 13:38 +0200, Marcin Hanclik a écrit :
> I cannot publish the source code now, also due to the immaturity of the tool.

I personally wouldn't mind that immaturity and would be happy to
contribute in making it more mature.

> The tool was developed to fit the format used within BONDI, it does not 
> understand the HTML format used in W3C (HTML is the output, input is WebIDL + 
> doxygen).

It's fairly straightforward to extract the WebIDLs from W3C specs (e.g.
using XSLT), and I can also imagining annotating these with doxygen
comments by more auto-extracting work.

Thanks,

Dom

Re: Widgets PAG seeks feedback on Widget Updates spec

[Jean-Claude Dufourd]

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

[Marcos Caceres]

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

[Nikunj R. Mehta]

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?

[Bil Corry]

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: Points of order on this WG

[Ian Hickson]

On Wed, 15 Jul 2009, Nikunj R. Mehta wrote:
>
> 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

Oops. Thanks, fixed.

-- 
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]

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

[Cameron McCormack]

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/