- From: Anne van Kesteren <annevk@opera.com>
- Date: Mon, 26 May 2008 14:40:30 +0200
- To: "Sunava Dutta" <sunavad@windows.microsoft.com>, "public-webapi@w3.org" <public-webapi@w3.org>
- Cc: "Chris Wilson" <Chris.Wilson@microsoft.com>, "IE8 Core AJAX SWAT Team" <ieajax@microsoft.com>
On Fri, 16 May 2008 23:14:02 +0200, Sunava Dutta <sunavad@windows.microsoft.com> wrote: > [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 I'm still not sure what you mean by this. XMLHttpRequest can't stand on its own, it depends on several other concepts, such as the Window object, the XML specification, the same origin policy as defined by HTML 5 at the moment, exceptions as defined by DOM Level 3 Core, eventing as defined by DOM Level 2 Events (no longer DOM Level 3 Events as that was not necessary), HTTP, etc. > 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. This is for going to PR, not when going to CR. > 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" Right, so that seems good. > 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. I don't have the bandwidth to do that. If someone has, please step up and do it, because that would indeed be most useful. For now, referencing HTML 5 on these matters seems the best thing for implementors. > 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. Agreed. >> 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. Yes, we can wait in CR I think. -- Anne van Kesteren <http://annevankesteren.nl/> <http://www.opera.com/>
Received on Monday, 26 May 2008 12:40:35 UTC