RE: [XHR] referencing HTML5



> -----Original Message-----
> From: public-webapi-request@w3.org [mailto:public-webapi-request@w3.org]
> On Behalf Of Anne van Kesteren
> Sent: Friday, May 16, 2008 2:16 AM
> To: public-webapi@w3.org
> Subject: [XHR] referencing HTML5
>
>
> There have been a lot of messages about referencing HTML5 and how we can
> mitigate that. I don't think that copying the text from HTML5 is an
> option. The Window specification is fairly complex and especially the
> interaction with browsing contexts is a complex bit of HTML5 that I don't
> feel confident taking over. The same goes for defining the origin policy.

[Sunava Dutta] I agree, copying everything will bloat this spec and will add complexity to the specification. I did make this point awhile back below (regarding linking to specifications that are in flux) and I'm glad to see concerns here being discussed.

" The draft frequently cross references specifications in the W3C.For example, the spec makes references to the DOM 3 events and core, namespaces in XML, Window Object 1.0 etc (Some of which are drafts themselves). We fail to see the value in implicitly embedding other large specs. Simplicity and standing on its own would be good."
http://lists.w3.org/Archives/Public/public-webapi/2007Sep/0043.html


The challenge of interlinking right now means that XHR should not go past CR unless those interlinked drafts are stabilized. I don’t think we can have a spec move past CR that references moving targets.
Also, how are we two ensure that two interoperable implementations exist (isn’t this a requirement for CR?) if this is the case? Pardon if I'm wrong.

Also, HTML 5.0 as Ian mentions (those aspects of HTML 5.0 that deal with XHR) should reflect existing implementations, or it quickly becomes an academic exercise and looses relevance.
Ian says: " HTML5 is describing existing practice on these matters, not defining new"

I would strongly urge the editor of the XHR spec to consider defining these outside of HTML 5.0 (maybe in the spec or link to it) in a way that reflects existing implementation since this is very tied to XHR as mentioned in the past by members. Having it outside of HTML 5.0 is OK as the charter of the merged WA Working Group (That accepts XHR as a deliverable) does not mention HTML 5.0 as an referenced specification.

If not then we should wait for HTML 5.0 to lockdown. (Or perhaps those sections of HTML 5.0 to lockdown)
Eitherway, focusing on this getting to REC by any means is not wise until it's done.

>
> If someone were to volunteer to define these outside of HTML5 we could
> refer to that specification but so far that has not happened.
>
> So we have two reasonable options I think:
>
> 1) Keep the references intact.
>
> 2) Make various things implementation defined and hint with non-normative
> notes that this will be defined by HTML5 in the future.
>
> Option two would be feasible but implementors have actually requested that
> we define in detail how URIs are resolved and what exactly the same-origin
> policy implies for XMLHttpRequest. I don't think it's worth dropping all
> that work on the floor.
[Sunava Dutta] Your argument that implementers have requested this is fine, but then it's the specs responsibility to address those sections (the relevant behavior) in the spec or wait till those are settled.
>
>
> --
> Anne van Kesteren
> <http://annevankesteren.nl/>
> <http://www.opera.com/>
>

Received on Friday, 16 May 2008 21:14:48 UTC