[widgets] HTML5 dependency blocking Widget Interface Proposed Recommendation

2012-04-19 Thread Arthur Barstow

Hi All,

As I understand it, the W3C's publication precedence re normative 
references for a Proposed Recommendation, is that all W3C normative 
references must be at CR or a later maturity level.


With today's publication of a CR of Web IDL [WebIDL-CR], the only W3C 
normative reference in the Widget Interface Candidate Recommendation 
[TWI-CR] that is not at CR or later is HTML5.


Philippe, Ian - my understanding is that if the WG can show its uses of 
HTML5 are restricted to stable parts of the HTML5 spec, the Director 
will relax this publication precedence i.e. the Widget Interface may be 
published as a Proposed Recommendation. Is this correct?


Marcos - would you please enumerate the CR's uses of HTML5 and state 
whether each usage is to a stable part of HTML5?


-Thanks, AB

[TWI-CR] http://www.w3.org/TR/2011/CR-widgets-apis-20111213/
[WebIDL-CR] http://www.w3.org/TR/2012/CR-WebIDL-20120419/





Re: [widgets] HTML5 dependency blocking Widget Interface Proposed Recommendation

2012-04-19 Thread Ian Jacobs

On 19 Apr 2012, at 7:48 AM, Arthur Barstow wrote:

 Hi All,
 
 As I understand it, the W3C's publication precedence re normative references 
 for a Proposed Recommendation, is that all W3C normative references must be 
 at CR or a later maturity level.
 
 With today's publication of a CR of Web IDL [WebIDL-CR], the only W3C 
 normative reference in the Widget Interface Candidate Recommendation [TWI-CR] 
 that is not at CR or later is HTML5.
 
 Philippe, Ian - my understanding is that if the WG can show its uses of HTML5 
 are restricted to stable parts of the HTML5 spec, the Director will relax 
 this publication precedence i.e. the Widget Interface may be published as a 
 Proposed Recommendation. Is this correct?

This is my expectation:
 https://lists.w3.org/Archives/Member/chairs/2011JulSep/0092.html

Ian

 
 Marcos - would you please enumerate the CR's uses of HTML5 and state whether 
 each usage is to a stable part of HTML5?
 
 -Thanks, AB
 
 [TWI-CR] http://www.w3.org/TR/2011/CR-widgets-apis-20111213/
 [WebIDL-CR] http://www.w3.org/TR/2012/CR-WebIDL-20120419/
 
 
 

--
Ian Jacobs (i...@w3.org)http://www.w3.org/People/Jacobs/
Tel:  +1 718 260 9447




Re: [widgets] HTML5 dependency blocking Widget Interface Proposed Recommendation

2012-04-19 Thread Marcos Caceres



On Thursday, 19 April 2012 at 13:48, Arthur Barstow wrote:

 Marcos - would you please enumerate the CR's uses of HTML5 and state 
 whether each usage is to a stable part of HTML5?


1. A browsing context that comes into existence after initialization. The 
concept of a browsing context is defined in [HTML]. Multiple widget instances 
can be instantiated from a single widget package. A widget instance is unique 
and does not share any DOM attribute values, widget storage area, or [Web 
Storage] storage areas with any other widget instance. 

Browsing context is a concept - and a well understood one at that. 

2. User agent implementing [HTML]'s Window interface must implement the Widget 
interface as the widget attribute of the window object in the manner defined by 
the WindowWidget interface.

The window object is present in all browser implementations. Widgets to put any 
additional requirements on it.  

3. When getting or setting the preferences attribute, if the origin of a 
widget instance is mutable (e.g., if the user agent allows document.domain to 
be dynamically changed), then the user agent must perform the preference-origin 
security check. The concept of origin is defined in [HTML].   

Origin is concept that is well understood - as is the same origin policy used 
by browsers. 

Hope that helps! 

-- 
Marcos Caceres
http://datadriven.com.au






Re: [widgets] HTML5 dependency blocking Widget Interface Proposed Recommendation

2012-04-19 Thread Arthur Barstow

On 4/19/12 8:57 AM, ext Ian Jacobs wrote:

On 19 Apr 2012, at 7:48 AM, Arthur Barstow wrote:


Hi All,

As I understand it, the W3C's publication precedence re normative references 
for a Proposed Recommendation, is that all W3C normative references must be at 
CR or a later maturity level.

With today's publication of a CR of Web IDL [WebIDL-CR], the only W3C normative 
reference in the Widget Interface Candidate Recommendation [TWI-CR] that is not 
at CR or later is HTML5.

Philippe, Ian - my understanding is that if the WG can show its uses of HTML5 
are restricted to stable parts of the HTML5 spec, the Director will relax this 
publication precedence i.e. the Widget Interface may be published as a Proposed 
Recommendation. Is this correct?

This is my expectation:
  https://lists.w3.org/Archives/Member/chairs/2011JulSep/0092.html


WebApps does all of its work in the Public. As such, would you or PLH 
please forward that email to a Public list (preferably public-webapps)?


-Thanks, AB





Re: [widgets] HTML5 dependency blocking Widget Interface Proposed Recommendation

2012-04-19 Thread Marcos Caceres


On Thursday, 19 April 2012 at 14:10, Arthur Barstow wrote:

 On 4/19/12 8:57 AM, ext Ian Jacobs wrote:
  On 19 Apr 2012, at 7:48 AM, Arthur Barstow wrote:
   
  This is my expectation:
  https://lists.w3.org/Archives/Member/chairs/2011JulSep/0092.html
  
  
  
 WebApps does all of its work in the Public. As such, would you or PLH  
 please forward that email to a Public list (preferably public-webapps)?

It says we can freely distribute the proposal to the group, so here it is:

Dear Chairs,

Documentation of our current practices for [0] for normative references
states:

   In general, documents do not advance to Recommendation with
normative references to W3C specifications that are not yet
Recommendations.

However, several Working Groups have expressed a desire to reference
the HTML5 specification [1] even as a draft. The current expectation [2]
is that the HTML5 specification will become a Recommendation in 2014.

To address the needs of these groups sooner than 2014, we propose the
following for normative references to HTML5 (and only to HTML5) from
specifications scheduled to become Recommendations before HTML5.

Please, provide feedback and comments on this proposal until 22
September 2011 . Unless there are objections, we plan to implement this
proposal shortly thereafter. Feel free to circulate this proposal to your
Working Groups.  

Philippe Le H├ęgaret and Ian Jacobs

[0] http://www.w3.org/Guide/transitions
[1] http://www.w3.org/TR/html5/
[2] http://www.w3.org/2011/02/htmlwg-pr.html

=
Proposal for Normative References While HTML5 is not a Recommendation

* A Working Group X may propose normative references from a Proposed
  Recommendation or Recommendation to a set of definitions or
  implementable features in the HTML5 specification [1].

* Working Group X must indicate the presence of these references in any  
  Proposed [Edited] Recommendation or Recommendation transition request.

* The Director will evaluate these references and approve them when
satisfied that Working Group X has provided evidence that:

- The HTML Working Group has addressed all issues associated with the
  referenced HTML5 features or definitions, and that all issues have
  been resolved at least 60 days before the date of Working Group X's
  transition request.

- All referenced HTML5 features have been implemented.  Preferably,
  Working Group X should be able to demonstrate two interoperable
  implementations of each feature. If the Director believes that
  immediate Advisory Committee review is critical to the success of a
  technical report, the Director may accept normative references even
  without adequate HTML5 implementation experience.  







CfC: publish Proposed Recommendation of Widget Interface; deadline April 26

2012-04-19 Thread Arthur Barstow
Now that the normative references for the Widget Interface spec have 
advanced and we have documented the spec only uses stable features of 
HTML5 [1], the Widget Interface is ready for publication as a Proposed 
Recommendation. As such, this is Call for Consensus to publish a PR of 
this spec using the following ED as the basis:


http://dev.w3.org/2006/waf/widgets-api/

Note the Process Document includes the following regarding the entrance 
criteria for a PR and the WG's requirements:


[[
http://www.w3.org/2005/10/Process-20051014/tr.html#cfr

* Shown that each feature of the technical report has been implemented. 
Preferably, the Working Group SHOULD be able to demonstrate two 
interoperable implementations of each feature.

]]

As documented in this spec's CR [2], the CR exit criteria was met before 
the CR was published.


If you have any comments about this proposal, please send them to 
public-webapps@w3.org by April 26 at the latest. Positive response is 
preferred and encouraged and silence will be considered as agreeing with 
the proposal.


-AB

[1] http://lists.w3.org/Archives/Public/public-webapps/2012AprJun/0246.html
[2] http://www.w3.org/TR/2011/CR-widgets-apis-20111213/





Re: [widgets] HTML5 dependency blocking Widget Interface Proposed Recommendation

2012-04-19 Thread Glenn Adams
On Thu, Apr 19, 2012 at 7:06 AM, Marcos Caceres marcosscace...@gmail.comwrote:

 On Thursday, 19 April 2012 at 13:48, Arthur Barstow wrote:
  Marcos - would you please enumerate the CR's uses of HTML5 and state
  whether each usage is to a stable part of HTML5?
 3. When getting or setting the preferences attribute, if the origin of a
 widget instance is mutable (e.g., if the user agent allows document.domain
 to be dynamically changed), then the user agent must perform the
 preference-origin security check. The concept of origin is defined in
 [HTML].

 Origin is concept that is well understood - as is the same origin policy
 used by browsers.


TWI [1] does not define the origin of a widget instance. Nor does HTML5.
It is also confusing to say that HTML5 defines the 'concept of origin',
given that it normatively refers to The Web Origin Concept [2]. TWI needs
to be more specific about what aspect of Origin is being referenced and
where that specific aspect is defined.

[1] http://www.w3.org/TR/2011/CR-widgets-apis-20111213/
[2] http://tools.ietf.org/html/rfc6454


Re: [widgets] HTML5 dependency blocking Widget Interface Proposed Recommendation

2012-04-19 Thread Marcos Caceres




On Thursday, 19 April 2012 at 15:58, Glenn Adams wrote:

 
 On Thu, Apr 19, 2012 at 7:06 AM, Marcos Caceres marcosscace...@gmail.com 
 (mailto:marcosscace...@gmail.com) wrote:
  On Thursday, 19 April 2012 at 13:48, Arthur Barstow wrote:
   Marcos - would you please enumerate the CR's uses of HTML5 and state
   whether each usage is to a stable part of HTML5?
  
  3. When getting or setting the preferences attribute, if the origin of a 
  widget instance is mutable (e.g., if the user agent allows document.domain 
  to be dynamically changed), then the user agent must perform the 
  preference-origin security check. The concept of origin is defined in 
  [HTML]. 
  Origin is concept that is well understood - as is the same origin policy 
  used by browsers.
 
 
 TWI [1] does not define the origin of a widget instance.
That's because they are not bound to any particular URI scheme. Just to some 
origin.  
 Nor does HTML5. It is also confusing to say that HTML5 defines the 'concept 
 of origin', given that it normatively refers to The Web Origin Concept [2]. 
 TWI needs to be more specific about what aspect of Origin is being referenced 
 and where that specific aspect is defined.

As there are no interoperability issues, I don't agree the TWI spec needs to be 
updated any further. It's just a simple spec and any further clarifications 
would just be academic.   
 
 [1] http://www.w3.org/TR/2011/CR-widgets-apis-20111213/
 [2] http://tools.ietf.org/html/rfc6454


-- 
Marcos Caceres
http://datadriven.com.au






Re: [widgets] HTML5 dependency blocking Widget Interface Proposed Recommendation

2012-04-19 Thread Glenn Adams
On Thu, Apr 19, 2012 at 9:02 AM, Marcos Caceres marcosscace...@gmail.comwrote:

 On Thursday, 19 April 2012 at 15:58, Glenn Adams wrote:

 
  On Thu, Apr 19, 2012 at 7:06 AM, Marcos Caceres 
 marcosscace...@gmail.com (mailto:marcosscace...@gmail.com) wrote:
   On Thursday, 19 April 2012 at 13:48, Arthur Barstow wrote:
Marcos - would you please enumerate the CR's uses of HTML5 and state
whether each usage is to a stable part of HTML5?
  
   3. When getting or setting the preferences attribute, if the origin
 of a widget instance is mutable (e.g., if the user agent allows
 document.domain to be dynamically changed), then the user agent must
 perform the preference-origin security check. The concept of origin is
 defined in [HTML].
   Origin is concept that is well understood - as is the same origin
 policy used by browsers.
 
 
  TWI [1] does not define the origin of a widget instance.
 That's because they are not bound to any particular URI scheme. Just to
 some origin.
  Nor does HTML5. It is also confusing to say that HTML5 defines the
 'concept of origin', given that it normatively refers to The Web Origin
 Concept [2]. TWI needs to be more specific about what aspect of Origin is
 being referenced and where that specific aspect is defined.

 As there are no interoperability issues, I don't agree the TWI spec needs
 to be updated any further. It's just a simple spec and any further
 clarifications would just be academic.
 
  [1] http://www.w3.org/TR/2011/CR-widgets-apis-20111213/
  [2] http://tools.ietf.org/html/rfc6454


in that case, please record an objection on my part


Re: [widgets] HTML5 dependency blocking Widget Interface Proposed Recommendation

2012-04-19 Thread Marcos Caceres



On Thursday, 19 April 2012 at 16:04, Glenn Adams wrote:

 
 On Thu, Apr 19, 2012 at 9:02 AM, Marcos Caceres marcosscace...@gmail.com 
 (mailto:marcosscace...@gmail.com) wrote:
  On Thursday, 19 April 2012 at 15:58, Glenn Adams wrote:
  
   
   On Thu, Apr 19, 2012 at 7:06 AM, Marcos Caceres marcosscace...@gmail.com 
   (mailto:marcosscace...@gmail.com) (mailto:marcosscace...@gmail.com) 
   wrote:
On Thursday, 19 April 2012 at 13:48, Arthur Barstow wrote:
 Marcos - would you please enumerate the CR's uses of HTML5 and state
 whether each usage is to a stable part of HTML5?


3. When getting or setting the preferences attribute, if the origin of 
a widget instance is mutable (e.g., if the user agent allows 
document.domain to be dynamically changed), then the user agent must 
perform the preference-origin security check. The concept of origin is 
defined in [HTML].
Origin is concept that is well understood - as is the same origin 
policy used by browsers.
   
   
   
   TWI [1] does not define the origin of a widget instance.
  That's because they are not bound to any particular URI scheme. Just to 
  some origin.
   Nor does HTML5. It is also confusing to say that HTML5 defines the 
   'concept of origin', given that it normatively refers to The Web Origin 
   Concept [2]. TWI needs to be more specific about what aspect of Origin is 
   being referenced and where that specific aspect is defined.
  
  
  As there are no interoperability issues, I don't agree the TWI spec needs 
  to be updated any further. It's just a simple spec and any further 
  clarifications would just be academic.
   
   [1] http://www.w3.org/TR/2011/CR-widgets-apis-20111213/
   [2] http://tools.ietf.org/html/rfc6454
  
 
 
 in that case, please record an objection on my part
 

What, exactly, are you objecting to? Can you demonstrate that there is an 
issue?  




Re: [widgets] HTML5 dependency blocking Widget Interface Proposed Recommendation

2012-04-19 Thread Glenn Adams
On Thu, Apr 19, 2012 at 9:04 AM, Glenn Adams gl...@skynav.com wrote:


 On Thu, Apr 19, 2012 at 9:02 AM, Marcos Caceres 
 marcosscace...@gmail.comwrote:

 On Thursday, 19 April 2012 at 15:58, Glenn Adams wrote:

 
  On Thu, Apr 19, 2012 at 7:06 AM, Marcos Caceres 
 marcosscace...@gmail.com (mailto:marcosscace...@gmail.com) wrote:
   On Thursday, 19 April 2012 at 13:48, Arthur Barstow wrote:
Marcos - would you please enumerate the CR's uses of HTML5 and state
whether each usage is to a stable part of HTML5?
  
   3. When getting or setting the preferences attribute, if the origin
 of a widget instance is mutable (e.g., if the user agent allows
 document.domain to be dynamically changed), then the user agent must
 perform the preference-origin security check. The concept of origin is
 defined in [HTML].
   Origin is concept that is well understood - as is the same origin
 policy used by browsers.
 
 
  TWI [1] does not define the origin of a widget instance.
 That's because they are not bound to any particular URI scheme. Just to
 some origin.
  Nor does HTML5. It is also confusing to say that HTML5 defines the
 'concept of origin', given that it normatively refers to The Web Origin
 Concept [2]. TWI needs to be more specific about what aspect of Origin is
 being referenced and where that specific aspect is defined.

 As there are no interoperability issues, I don't agree the TWI spec needs
 to be updated any further. It's just a simple spec and any further
 clarifications would just be academic.
 
  [1] http://www.w3.org/TR/2011/CR-widgets-apis-20111213/
  [2] http://tools.ietf.org/html/rfc6454


 in that case, please record an objection on my part


just to be clear, I mean an objection to publishing as PR unless this is
clarified; i believe this is an issue because the concept and use of origin
is (1) very complex and (2) thus prone to misinterpretation; for example,
it is not well recognized that HTML5 itself does not require a UA to send
an Origin header in a URL request (see [3])

[3] https://www.w3.org/Bugs/Public/show_bug.cgi?id=16574


Re: [widgets] HTML5 dependency blocking Widget Interface Proposed Recommendation

2012-04-19 Thread Marcos Caceres



On Thursday, 19 April 2012 at 16:11, Glenn Adams wrote:

  in that case, please record an objection on my part 
 
 
 just to be clear, I mean an objection to publishing as PR unless this is 
 clarified; i believe this is an issue because the concept and use of origin 
 is (1) very complex and (2) thus prone to misinterpretation; for example, it 
 is not well recognized that HTML5 itself does not require a UA to send an 
 Origin header in a URL request (see [3])
Yes, but those are issue of RFC6454 and the HTML5 spec (as well as Web 
Storage). But what does this have to do with Widgets? 




Re: [widgets] HTML5 dependency blocking Widget Interface Proposed Recommendation

2012-04-19 Thread Marcos Caceres



On Thursday, 19 April 2012 at 16:14, Marcos Caceres wrote:

 
 
 
 On Thursday, 19 April 2012 at 16:11, Glenn Adams wrote:
 
   in that case, please record an objection on my part 
  
  
  just to be clear, I mean an objection to publishing as PR unless this is 
  clarified; i believe this is an issue because the concept and use of origin 
  is (1) very complex and (2) thus prone to misinterpretation; for example, 
  it is not well recognized that HTML5 itself does not require a UA to send 
  an Origin header in a URL request (see [3])
 Yes, but those are issue of RFC6454 and the HTML5 spec (as well as Web 
 Storage). But what does this have to do with Widgets? 

Glenn and I discussed this on IRC. Glenn suggested I add the following to the 
definition of a widget instance:

 The origin of a widget instance is the origin of the Document object 
associated with the widget instance's browsing context.

I agree with Glenns recommendation, so I've go ahead and added that:

http://dev.w3.org/2006/waf/widgets-api/#widget-instance


-- 
Marcos Caceres
http://datadriven.com.au





Re: [widgets] HTML5 dependency blocking Widget Interface Proposed Recommendation

2012-04-19 Thread Glenn Adams
On Thu, Apr 19, 2012 at 9:49 AM, Marcos Caceres w...@marcosc.com wrote:

 On Thursday, 19 April 2012 at 16:14, Marcos Caceres wrote:
  On Thursday, 19 April 2012 at 16:11, Glenn Adams wrote:
 
in that case, please record an objection on my part
   just to be clear, I mean an objection to publishing as PR unless this
 is clarified; i believe this is an issue because the concept and use of
 origin is (1) very complex and (2) thus prone to misinterpretation; for
 example, it is not well recognized that HTML5 itself does not require a UA
 to send an Origin header in a URL request (see [3])
  Yes, but those are issue of RFC6454 and the HTML5 spec (as well as Web
 Storage). But what does this have to do with Widgets?

 Glenn and I discussed this on IRC. Glenn suggested I add the following to
 the definition of a widget instance:

  The origin of a widget instance is the origin of the Document object
 associated with the widget instance's browsing context.

 I agree with Glenns recommendation, so I've go ahead and added that:

 http://dev.w3.org/2006/waf/widgets-api/#widget-instance


thanks Marcos, I drop my objection; regarding the reference to HTML5, it
would be an improvement if you could change section 6.5 from:

The concept of origin is defined in
[HTML]http://dev.w3.org/2006/waf/widgets-api/#html5
.

to

The concept of origin of a Document object is defined in
[HTML]http://dev.w3.org/2006/waf/widgets-api/#html5
.


Re: [widgets] HTML5 dependency blocking Widget Interface Proposed Recommendation

2012-04-19 Thread Glenn Adams
On Thu, Apr 19, 2012 at 10:02 AM, Marcos Caceres
marcosscace...@gmail.comwrote:

 On Thursday, 19 April 2012 at 16:57, Glenn Adams wrote:
   thanks Marcos, I drop my objection; regarding the reference to HTML5,

 Yay! :)
  it would be an improvement if you could change section 6.5 from:
 
  The concept of origin is defined in [HTML] (
 http://dev.w3.org/2006/waf/widgets-api/#html5).
 
  to
 
  The concept of origin of a Document object is defined in [HTML] (
 http://dev.w3.org/2006/waf/widgets-api/#html5).
 Done, and committed:
 http://dev.w3.org/2006/waf/widgets-api/#origin


thanks for the speed of light resolution! :)


Re: [CORS] Applying preflight cache to an entire domain?

2012-04-19 Thread Monsur Hossain
Thanks for the clarification, that makes sense.

A little background on why I'm thinking about this. I've been investigating
CORS performance on mobile. Mobile is a great use case for CORS since it is
mostly guaranteed to be supported (at least on iOS and Android). However,
the cost of making two HTTP requests per logical request can be expensive,
especially in a mobile environment.

The preflight cache is keyed on the origin/url pair. Furthermore, Chrome
includes a max-preflight time on 5 minutes (not sure if other browsers do
the same). So in an ideal scenario, the browser will be making one
preflight request every 5 minutes.

That doesn't sound so bad, but consider a typical RESTful API, where each
resource is represented by a different url. The preflight cache will yield
a cache hit in very narrow situations (perhaps while updating the same
resource over and over again, or polling a particular endpoint).

So I'm concerned that the cache-hit ratio in real world applications will
actually be quite low. It would be nice to have some sort of solution to
this.

Thanks,
Monsur


On Wed, Apr 18, 2012 at 11:50 AM, Anne van Kesteren ann...@opera.comwrote:

 On Wed, 18 Apr 2012 18:34:42 +0200, Monsur Hossain mon...@gmail.com
 wrote:

 Ah thank you! I agree that url canonicalization is a difficult issue to
 solve. FWIW, I was envisioning something much simpler. The CORS spec makes
 it clear that cache lookup should be done by origin and request url. So
 instead of specifying a url to this Access-Control-Policy-Path header, it
 would be just one of three values:

   - url - (default behavior) Cache lookup is done by origin and request

   url, as the spec indicates now
   - origin - Cache lookup is done by origin only. Preflight response

   applies to any request from this origin.
   - any - Cache lookup applies to *any* origin making requests to the

   domain.

 This would fit in with the current preflight caching model while still
 allowing some flexibility to servers implementing CORS.


 The reason why we wanted it scoped was because people had concerns about
 giving any URL on a server control over which other resources would end up
 being shared. The scenarios typically involved large organizations with
 many different teams operating on a single origin. If one of those teams
 thinks sharing with everyone is fine, the rest can be comprised. And such a
 mistake is rather easy to make.

 Another general concern that has been frequently raised and why the
 specification has so many flags for enabling additional features such as
 headers and methods, is that people easily shoot themselves in the foot.
 Your proposal makes it rather easy for them to shoot themselves in the foot.



 --
 Anne van Kesteren
 http://annevankesteren.nl/