Re: XMLHttpRequest Comments from W3C Forms WG
On Mon, Dec 21, 2009 at 1:12 AM, Jonas Sicking jo...@sicking.cc wrote: On Sun, Dec 20, 2009 at 2:39 PM, Marcos Caceres marc...@opera.com wrote: On Sun, Dec 20, 2009 at 10:43 PM, Julian Reschke julian.resc...@gmx.de wrote: Marcos Caceres wrote: ... Yeah, you are right. I guess we get so used to having these crappy retrospective APIs around that one forgets that things could be done in better ways - thankfully decent frameworks have been built around them to make these things usable. ... Maybe that could be a lesson for XHR2? Perhaps, but I haven't been following the XHR2 work - it could already address all this, for all I know:) Nevertheless, if there hasn't already happened, it would be good if people who have worked on making XHR actually usable would contribute to making XHR Level 2 more aligned with how XHR is used on the ground - thinking Prototype, Dojo, JQuery, etc. Seems a bit ridiculous that everyone is building effectively the same wrappers around XHR to make it usable when all this could be done much faster if it was implemented natively in the browser. Apart from having a whinge, I don't have a better proposal for how this could be done - I haven't thought about it, and there are people much more qualified then me to do that. I can only hope that those working on the spec have looked at how the frameworks do ajax and if lessons can be taken and specified out of that... or that framework creators contribute back to the standardization process from the wild. Note that just because something is implemented natively in the browser doesn't mean it's faster. For example what a lot of libraries that wrap XHR do is to cover up browser differences, as well as present a friendlier syntax. The overhead of doing this in JS is in the order of fractions of milliseconds, whereas the the full request usually take several tenths of a second. Performance optimizing the JS overhead here is clearly not worth it. I agree, there are instances where it doesn't really make a difference. However, there is evidence that in some APIs, it did make some sense to implement native support (Selectors API): http://ejohn.org/blog/queryselectorall-in-firefox-31/ I guess by faster I really meant more logical and usable, meaning hopefully faster for developers to work with. Like i don't seem to get as nauseous when I use JQuery compared to when I use native XHR. Anyway, that's just me and I don't want to take this discussion down some rathole. I do however definitely agree that we should be talking to web developers in any spec we develop, XHR included. If you mean average web developer (say, someone that uses JQuery to build some website), I think we can all agree that this would be nice but probably impractical. I think it would be better to engage those who built the great JS frameworks, which already engage with developers on the ground and have made the innovations that have made the unruly mess that is the Web development a bit more tolerable. These are usually the people that, in my experience, know a lot about incompatibilities across UAs and, more importantly, can give an insight as to how developers actually wish JavaScript and related APIs should look and behave though, it could lead to creepy method names, like $$() :D Kind regards, Marcos -- Marcos Caceres http://datadriven.com.au
Re: XMLHttpRequest Comments from W3C Forms WG
On Sat, Dec 19, 2009 at 4:01 AM, Alex Russell a...@dojotoolkit.org wrote: On Dec 18, 2009, at 3:09 PM, Marcos Caceres wrote: On Fri, Dec 18, 2009 at 4:40 AM, Maciej Stachowiak m...@apple.com wrote: On Dec 17, 2009, at 3:15 PM, Klotz, Leigh wrote: OK, so is the conclusion that XHR is implementable only in HTML5 and should be re-titled XMLHttpRequest in HTML5 or something similar? I think your premise is false, and I don't such a retitling would be helpful. The XHR spec does not require a full implementation of HTML5. It only references some concepts from HTML5. The XHR spec could be implemented in an SVG or HTML4 or XHTML 1.0 implementation that did not support most aspects of HTML5 at all, as long as it could satisfy the requirements implied by those definitions. Your proposed title change would imply that the XHR spec could only be implemented by an HTML5 UA, but that is not accurate. So, basically, what you are saying is that you can't pick up this spec and, say, implement it in [insert favorite programming language] easily without a whole bunch of baggage from HTML5? Seems like pretty poor engineering, but that might not be the fault of the specification (i.e., given that XHR is a reverse engineering of something that is closely tied to browsers). Its a shame though that we can't liberate these things from browser behavior so they are more generally applicable. I've seen XHR implemented in other classes of product, but it'd be a shame if such products can't ever conform to the spec. That's sort of a perverse way to look at it. It's not like XHR is a *good* API. It's a passible Win32 COM interface, but you'd want a lot more control over many aspects of the HTTP discussion if you were doing this in an environment that's not a browser. What other environment has a same-origin policy? Unless the other language you're talking about is C++, I don't think anyone should be toting XHR around with them like it's some sort of a liberated gem. It's a bad JS API and would be as bad (or worse) in many other dynamic languages. Yeah, you are right. I guess we get so used to having these crappy retrospective APIs around that one forgets that things could be done in better ways - thankfully decent frameworks have been built around them to make these things usable. -- Marcos Caceres http://datadriven.com.au
Re: XMLHttpRequest Comments from W3C Forms WG
Marcos Caceres wrote: ... Yeah, you are right. I guess we get so used to having these crappy retrospective APIs around that one forgets that things could be done in better ways - thankfully decent frameworks have been built around them to make these things usable. ... Maybe that could be a lesson for XHR2? BR, Julian
Re: XMLHttpRequest Comments from W3C Forms WG
On Sun, Dec 20, 2009 at 10:43 PM, Julian Reschke julian.resc...@gmx.de wrote: Marcos Caceres wrote: ... Yeah, you are right. I guess we get so used to having these crappy retrospective APIs around that one forgets that things could be done in better ways - thankfully decent frameworks have been built around them to make these things usable. ... Maybe that could be a lesson for XHR2? Perhaps, but I haven't been following the XHR2 work - it could already address all this, for all I know:) Nevertheless, if there hasn't already happened, it would be good if people who have worked on making XHR actually usable would contribute to making XHR Level 2 more aligned with how XHR is used on the ground - thinking Prototype, Dojo, JQuery, etc. Seems a bit ridiculous that everyone is building effectively the same wrappers around XHR to make it usable when all this could be done much faster if it was implemented natively in the browser. Apart from having a whinge, I don't have a better proposal for how this could be done - I haven't thought about it, and there are people much more qualified then me to do that. I can only hope that those working on the spec have looked at how the frameworks do ajax and if lessons can be taken and specified out of that... or that framework creators contribute back to the standardization process from the wild. -- Marcos Caceres http://datadriven.com.au
Re: XMLHttpRequest Comments from W3C Forms WG
On Sun, Dec 20, 2009 at 2:39 PM, Marcos Caceres marc...@opera.com wrote: On Sun, Dec 20, 2009 at 10:43 PM, Julian Reschke julian.resc...@gmx.de wrote: Marcos Caceres wrote: ... Yeah, you are right. I guess we get so used to having these crappy retrospective APIs around that one forgets that things could be done in better ways - thankfully decent frameworks have been built around them to make these things usable. ... Maybe that could be a lesson for XHR2? Perhaps, but I haven't been following the XHR2 work - it could already address all this, for all I know:) Nevertheless, if there hasn't already happened, it would be good if people who have worked on making XHR actually usable would contribute to making XHR Level 2 more aligned with how XHR is used on the ground - thinking Prototype, Dojo, JQuery, etc. Seems a bit ridiculous that everyone is building effectively the same wrappers around XHR to make it usable when all this could be done much faster if it was implemented natively in the browser. Apart from having a whinge, I don't have a better proposal for how this could be done - I haven't thought about it, and there are people much more qualified then me to do that. I can only hope that those working on the spec have looked at how the frameworks do ajax and if lessons can be taken and specified out of that... or that framework creators contribute back to the standardization process from the wild. Note that just because something is implemented natively in the browser doesn't mean it's faster. For example what a lot of libraries that wrap XHR do is to cover up browser differences, as well as present a friendlier syntax. The overhead of doing this in JS is in the order of fractions of milliseconds, whereas the the full request usually take several tenths of a second. Performance optimizing the JS overhead here is clearly not worth it. I do however definitely agree that we should be talking to web developers in any spec we develop, XHR included. / Jonas
Re: XMLHttpRequest Comments from W3C Forms WG
On Dec 16, 2009, at 21:47, Klotz, Leigh wrote: I'd like to suggest that the main issue is dependency of the XHR document on concepts where HTML5 is the only specification that defines several core concepts of the Web platform architecture, such as event loops, event handler attributes, Etc. A user agent that doesn't implement the core concepts isn't much use for browsing the Web. Since the point of the XHR spec is getting interop among Web browsers, it isn't a good allocation of resources to make XHR not depend on things that a user agent that is suitable for browsing the Web needs to support anyway. XHR interop doesn't matter much if XHR is transplanted into an environment where the other pieces fail to be interoperable with Web browsing software. That is, in such a case, it isn't much use if XHR itself works like XHR in browsers--the system as a whole still doesn't interoperate with Web browsers. -- Henri Sivonen hsivo...@iki.fi http://hsivonen.iki.fi/
RE: XMLHttpRequest Comments from W3C Forms WG
If XHR is wholly dependent on HTML5 then it should either be moved into the HTML5 recommendation-track document, or renamed XHR for HTML5. Ian has made a point that modularizing HTML5 itself is a large task; it's not clear that the same applies to this XHR document, at least to the same degree of work required. I don't see what harm comes from waiting to advance this XHR document until the necessary work has been done. Leigh. -Original Message- From: Henri Sivonen [mailto:hsivo...@iki.fi] Sent: Thursday, December 17, 2009 12:12 AM To: Klotz, Leigh Cc: Anne van Kesteren; WebApps WG; Forms WG Subject: Re: XMLHttpRequest Comments from W3C Forms WG On Dec 16, 2009, at 21:47, Klotz, Leigh wrote: I'd like to suggest that the main issue is dependency of the XHR document on concepts where HTML5 is the only specification that defines several core concepts of the Web platform architecture, such as event loops, event handler attributes, Etc. A user agent that doesn't implement the core concepts isn't much use for browsing the Web. Since the point of the XHR spec is getting interop among Web browsers, it isn't a good allocation of resources to make XHR not depend on things that a user agent that is suitable for browsing the Web needs to support anyway. XHR interop doesn't matter much if XHR is transplanted into an environment where the other pieces fail to be interoperable with Web browsing software. That is, in such a case, it isn't much use if XHR itself works like XHR in browsers--the system as a whole still doesn't interoperate with Web browsers. -- Henri Sivonen hsivo...@iki.fi http://hsivonen.iki.fi/
Re: XMLHttpRequest Comments from W3C Forms WG
On Thu, Dec 17, 2009 at 9:10 AM, Klotz, Leigh leigh.kl...@xerox.com wrote: If XHR is wholly dependent on HTML5 then it should either be moved into the HTML5 recommendation-track document, or renamed XHR for HTML5. Ian has made a point that modularizing HTML5 itself is a large task; it's not clear that the same applies to this XHR document, at least to the same degree of work required. I don't see what harm comes from waiting to advance this XHR document until the necessary work has been done. XHR isn't wholly dependent on HTML5. It is however dependent on a few things that are currently only defined by the HTML5 specification. This means that if someone wants to implement XHR they will have to read parts of the HTML5 specification, and implement a few things defined in that specification. It does *not* however mean that if someone wants to implement XHR they will have to implement all, or even a significant portion, of the HTML5 specification. I hope that makes it clear? Yes, we could move XHR into the HTML5 specification, but I don't understand what problems that would solve. Feel free to elaborate. / Jonas
RE: XMLHttpRequest Comments from W3C Forms WG
Jonas, Thank you for your response; comments below: -Original Message- From: Jonas Sicking [mailto:jo...@sicking.cc] Sent: Thursday, December 17, 2009 9:22 AM To: Klotz, Leigh Cc: Henri Sivonen; Anne van Kesteren; WebApps WG; Forms WG Subject: Re: XMLHttpRequest Comments from W3C Forms WG On Thu, Dec 17, 2009 at 9:10 AM, Klotz, Leigh leigh.kl...@xerox.com wrote: If XHR is wholly dependent on HTML5 then it should either be moved into the HTML5 recommendation-track document, or renamed XHR for HTML5. Ian has made a point that modularizing HTML5 itself is a large task; it's not clear that the same applies to this XHR document, at least to the same degree of work required. I don't see what harm comes from waiting to advance this XHR document until the necessary work has been done. XHR isn't wholly dependent on HTML5. It is however dependent on a few things that are currently only defined by the HTML5 specification. This means that if someone wants to implement XHR they will have to read parts of the HTML5 specification, and implement a few things defined in that specification. It does *not* however mean that if someone wants to implement XHR they will have to implement all, or even a significant portion, of the HTML5 specification. I hope that makes it clear? The Forms WG comment is that those items be abstracted out as requirements for any host of XHR, so that XHR need not depend on HTML5, but can interoperate with any system which provides those few things. One easy way to dot his is to split the XHR document in two, with one document called XHR which lists the dependencies, and another called XHR For HTML5 which satisfies them. The amount of text changed need not be large: the references to HTML5 need to be changed to Requirements for host languages. (Moving away from monolithic specs and towards more interoperable document is one of our goals for next year.) Yes, we could move XHR into the HTML5 specification, but I don't understand what problems that would solve. Feel free to elaborate. I agree, it's not desirable at all, but it's the current state; the XHR document currently works only with HTML5. That's why we're suggesting an alternative that preserves the dependency on HTML5 for HTML5 integration, yet allows other implementations. / Jonas Leigh.
RE: XMLHttpRequest Comments from W3C Forms WG
Jonas, I apologize if you and other group members consider this to be a pedantic exercise, but it's a necessary part of making the specification reusable. -Original Message- From: Jonas Sicking [mailto:jo...@sicking.cc] Sent: Thursday, December 17, 2009 9:45 AM To: Klotz, Leigh Cc: Henri Sivonen; Anne van Kesteren; WebApps WG; Forms WG Subject: Re: XMLHttpRequest Comments from W3C Forms WG ... I don't think I understand your suggested changes. As long as the concepts that XHR uses are only defined in the HTML5 spec, XHR will always require that those things from the HTML5 spec are implemented when implementing XHR. This doesn't seem to change even if the XHR spec is split into two. XHR requires things; the things might come from HTML5, though any sufficient definition of them could come from somewhere else. It's up to the implementor of the XHR spec to say where the things come from. HTML5 implementors would obviously choose to provide the HTML5 definitions. This could be done by splitting the XHR document in two, with one part called XHR saying I need things and another part called XHR for HTML5 saying I have perfectly fine things here from HTML5 XHR to use. HTML5 implements would then be implementing XHR for HTML5, which is mete and just. However I don't really understand what specifically you are suggesting should live in the two XHR specs, so I could very well be misunderstanding you. Could you describe that in more detail? It's in the previous trail on this topic, and Ian and Anne have also variously listed the items. Please take the example of one dependency, that of origin and base from Anne's message of October 8, 2009. Anne explains the strategy below: If you reuse it you have to define the XMLHttpRequest origin and XMLHttpRequest base URL. From: Anne van Kesteren annevk at opera.com Subject: Re: [XHR] LC comments from the XForms Working Group Date: 2009-10-08 15:31:27 GMT On Tue, 17 Jun 2008 05:24:48 +0200, Boris Zbarsky bzbarsky at mit.edu wrote: Anne van Kesteren wrote: It would change the conformance criteria. I'm not sure that's a good idea. Especially since the use case put forward is mostly theoretical. Overall, I'm still not convinced this is a good idea. It doesn't seem necessarily that theoretical to me, for what it's worth. Anne, do you happen to have a more or less complete list of the current dependencies of XHR on Window, buy chance? I think that information would be very helpful in seeing where things stand. To wrap this up, I changed XMLHttpRequest some time ago so it can be used in other contexts as well now. If you reuse it you have to define the XMLHttpRequest origin and XMLHttpRequest base URL. My apologies for being a bit stubborn on this earlier. It was mostly because I was hesitant reworking how everything was put together, but it turned out that had to happen anyway. Hopefully it can now be of use to the Forms WG. Kind regards, -- Anne van Kesteren http://annevankesteren.nl/ So, to be clear, here's how do complete the change for the specific dependency that Anne calls about above. (This process is repeated for each dependency of XHR on HTML5.) Cf. section http://www.w3.org/TR/2009/WD-XMLHttpRequest-20091119/#origin-and-base-url Each XMLHttpRequest object has an associated XMLHttpRequest origin and an XMLHttpRequest base URL. This specification defines their values when the global object is represented by the Window object. When the XMLHttpRequest object used in other contexts their values will have to be defined as appropriate for that context. That is considered to be out of scope for this specification. This text still results in a normative reference to HTML5. So change the XHR document to this: Each XMLHttpRequest object has an associated XMLHttpRequest origin and an XMLHttpRequest base URL. This specification does not defines their values; they MUST be defined by the host integration. For an example integration with [HTML5 informative reference] see [XHR For HTML5 informative reference] Further, the actual definitions would be removed when the actually occur. Then the new rec-track document XHR for HTML5 would say this: Each XMLHttpRequest object has an associated XMLHttpRequest origin and an XMLHttpRequest base URL. This specification defines their values when the global object is represented by the Window object. And then go on to cite contain the actual text of the definitions pulled out from XHR. Leigh.
Re: XMLHttpRequest Comments from W3C Forms WG
From: Anne van Kesteren annevk at opera.com Subject: Re: [XHR] LC comments from the XForms Working Group Date: 2009-10-08 15:31:27 GMT On Tue, 17 Jun 2008 05:24:48 +0200, Boris Zbarsky bzbarsky at mit.edu wrote: Anne van Kesteren wrote: It would change the conformance criteria. I'm not sure that's a good idea. Especially since the use case put forward is mostly theoretical. Overall, I'm still not convinced this is a good idea. It doesn't seem necessarily that theoretical to me, for what it's worth. Anne, do you happen to have a more or less complete list of the current dependencies of XHR on Window, buy chance? I think that information would be very helpful in seeing where things stand. To wrap this up, I changed XMLHttpRequest some time ago so it can be used in other contexts as well now. If you reuse it you have to define the XMLHttpRequest origin and XMLHttpRequest base URL. My apologies for being a bit stubborn on this earlier. It was mostly because I was hesitant reworking how everything was put together, but it turned out that had to happen anyway. Hopefully it can now be of use to the Forms WG. Kind regards, -- Anne van Kesteren http://annevankesteren.nl/ So, to be clear, here's how do complete the change for the specific dependency that Anne calls about above. (This process is repeated for each dependency of XHR on HTML5.) Cf. section http://www.w3.org/TR/2009/WD-XMLHttpRequest-20091119/#origin-and-base-url Each XMLHttpRequest object has an associated XMLHttpRequest origin and an XMLHttpRequest base URL. This specification defines their values when the global object is represented by the Window object. When the XMLHttpRequest object used in other contexts their values will have to be defined as appropriate for that context. That is considered to be out of scope for this specification. This text still results in a normative reference to HTML5. So change the XHR document to this: Each XMLHttpRequest object has an associated XMLHttpRequest origin and an XMLHttpRequest base URL. This specification does not defines their values; they MUST be defined by the host integration. For an example integration with [HTML5 informative reference] see [XHR For HTML5 informative reference] Further, the actual definitions would be removed when the actually occur. Then the new rec-track document XHR for HTML5 would say this: Each XMLHttpRequest object has an associated XMLHttpRequest origin and an XMLHttpRequest base URL. This specification defines their values when the global object is represented by the Window object. And then go on to cite contain the actual text of the definitions pulled out from XHR. Ah, thanks for the concrete example. This makes it clear what you are suggesting. What you are saying makes sense. However it seems to add unnecessary overhead to split the spec in two to accomplish this, for the spec editor, for someone implementing the spec, and for someone using the spec. It would seem to be much lower overhead to put these things in an appendix or something similar. / Jonas
Re: XMLHttpRequest Comments from W3C Forms WG
On Thu, Dec 17, 2009 at 10:54 AM, Jonas Sicking jo...@sicking.cc wrote: From: Anne van Kesteren annevk at opera.com Subject: Re: [XHR] LC comments from the XForms Working Group Date: 2009-10-08 15:31:27 GMT On Tue, 17 Jun 2008 05:24:48 +0200, Boris Zbarsky bzbarsky at mit.edu wrote: Anne van Kesteren wrote: It would change the conformance criteria. I'm not sure that's a good idea. Especially since the use case put forward is mostly theoretical. Overall, I'm still not convinced this is a good idea. It doesn't seem necessarily that theoretical to me, for what it's worth. Anne, do you happen to have a more or less complete list of the current dependencies of XHR on Window, buy chance? I think that information would be very helpful in seeing where things stand. To wrap this up, I changed XMLHttpRequest some time ago so it can be used in other contexts as well now. If you reuse it you have to define the XMLHttpRequest origin and XMLHttpRequest base URL. My apologies for being a bit stubborn on this earlier. It was mostly because I was hesitant reworking how everything was put together, but it turned out that had to happen anyway. Hopefully it can now be of use to the Forms WG. Kind regards, -- Anne van Kesteren http://annevankesteren.nl/ So, to be clear, here's how do complete the change for the specific dependency that Anne calls about above. (This process is repeated for each dependency of XHR on HTML5.) Cf. section http://www.w3.org/TR/2009/WD-XMLHttpRequest-20091119/#origin-and-base-url Each XMLHttpRequest object has an associated XMLHttpRequest origin and an XMLHttpRequest base URL. This specification defines their values when the global object is represented by the Window object. When the XMLHttpRequest object used in other contexts their values will have to be defined as appropriate for that context. That is considered to be out of scope for this specification. This text still results in a normative reference to HTML5. So change the XHR document to this: Each XMLHttpRequest object has an associated XMLHttpRequest origin and an XMLHttpRequest base URL. This specification does not defines their values; they MUST be defined by the host integration. For an example integration with [HTML5 informative reference] see [XHR For HTML5 informative reference] Further, the actual definitions would be removed when the actually occur. Then the new rec-track document XHR for HTML5 would say this: Each XMLHttpRequest object has an associated XMLHttpRequest origin and an XMLHttpRequest base URL. This specification defines their values when the global object is represented by the Window object. And then go on to cite contain the actual text of the definitions pulled out from XHR. Ah, thanks for the concrete example. This makes it clear what you are suggesting. What you are saying makes sense. However it seems to add unnecessary overhead to split the spec in two to accomplish this, for the spec editor, for someone implementing the spec, and for someone using the spec. It would seem to be much lower overhead to put these things in an appendix or something similar. Though I just realized that I'm not sure all dependencies can be solved this way. How would you for example break the dependency on the event loop, currently only specified in the HTML5 spec (but implemented in basically every piece of software with a modern UI)? / Jonas
RE: XMLHttpRequest Comments from W3C Forms WG
-Original Message- From: Jonas Sicking [mailto:jo...@sicking.cc] Sent: Thursday, December 17, 2009 10:54 AM To: Klotz, Leigh Cc: Henri Sivonen; Anne van Kesteren; WebApps WG; Forms WG Subject: Re: XMLHttpRequest Comments from W3C Forms WG ...snip And then go on to cite contain the actual text of the definitions pulled out from XHR. Ah, thanks for the concrete example. This makes it clear what you are suggesting. What you are saying makes sense. However it seems to add unnecessary overhead to split the spec in two to accomplish this, for the spec editor, for someone implementing the spec, and for someone using the spec. It would seem to be much lower overhead to put these things in an appendix or something similar. As for someone using the spec, the XHR spec would remain small, and the XHR for HTML5 spec would remain small; all spec users would have small mind-sized bites to understand, and it would be clear that XHR works with both HTML5 and can be made to work with other specifications, so it seems a good solution to me. However, I'm not one of the Web API editors, so I don't want to say concretely how the problem must be solved, and wasn't directed to do so by the Forms WG comments. The example is the most obvious solution to me, as the problem is about inter-specification dependence, normative language, and conformance, and I believe it should be solved that way. The Forms WG comment is about the normative reference and the express dependence on the 688-page HTML5 document for definitions. Part of the issue was addressed in Anne's change, but there is no conformance section which declares the implementation optional, and the normative reference remains. Leigh.
RE: XMLHttpRequest Comments from W3C Forms WG
Jonas, I'm not sure how the dependency is specified in the XHR draft. Can you point me to it? The word event loop doesn't appear. I know how XForms defines synchronous vs. asynchronous submissions using XML Events (which are an XML syntax for accessing DOM Events), and XHR is directly specified using DOM Events. Leigh. P.S. Again, I'm not an editor for the Web API specs, so I can't really know how the WG would like to solve these dependency issues, but to the degree that I have technical competence I'm happy to explore possible solutions. This is of course outside the scope of my representation of the Forms WG comment, which is about the issue, not about its solutions. -Original Message- From: Jonas Sicking [mailto:jo...@sicking.cc] Sent: Thursday, December 17, 2009 11:06 AM To: Klotz, Leigh Cc: Henri Sivonen; Anne van Kesteren; WebApps WG; Forms WG Subject: Re: XMLHttpRequest Comments from W3C Forms WG ...snip Though I just realized that I'm not sure all dependencies can be solved this way. How would you for example break the dependency on the event loop, currently only specified in the HTML5 spec (but implemented in basically every piece of software with a modern UI)? / Jonas
Re: XMLHttpRequest Comments from W3C Forms WG
On Thu, Dec 17, 2009 at 11:18 AM, Klotz, Leigh leigh.kl...@xerox.com wrote: Jonas, I'm not sure how the dependency is specified in the XHR draft. Can you point me to it? The word event loop doesn't appear. The term queue a task is defined in HTML5, and uses the event loop. / Jonas
RE: XMLHttpRequest Comments from W3C Forms WG
-Original Message- From: Jonas Sicking [mailto:jo...@sicking.cc] Sent: Thursday, December 17, 2009 11:33 AM To: Klotz, Leigh Cc: Henri Sivonen; Anne van Kesteren; WebApps WG; Forms WG Subject: Re: XMLHttpRequest Comments from W3C Forms WG On Thu, Dec 17, 2009 at 11:18 AM, Klotz, Leigh leigh.kl...@xerox.com wrote: Jonas, I'm not sure how the dependency is specified in the XHR draft. Can you point me to it? The word event loop doesn't appear. The term queue a task is defined in HTML5, and uses the event loop. / Jonas Jonas, Thank you for finding it form me. I see the use of queue a task now.: http://www.w3.org/TR/2009/WD-XMLHttpRequest-20091119/#terminology The terms and algorithms fragment, scheme, document base URL, document's character encoding, event handler attributes, event handler event type, fully active, Function, innerHTML, origin, preferred MIME name, resolve a URL, same origin, storage mutex, task, task source, URL, URL character encoding, queue a task, and valid MIME type are defined by the HTML 5 specification. [HTML5] I'd be surprised if some of these aren't terms already defined elsewhere. URL for example, is surely not given a different definition in HTML5 from the definition in RFC 3986. The rest of these terms not elsewhere defined would need to be defined sufficiently by contract in the XHR document and satisfied in the HTML5 implementation document, yet left open for implementation by a collaborating spec for HTML5's implementation. In the case of queue a task, it appears to be used in XHR, but event loop is not used in XHR. While I can't really comment on whether XHR should leave to the implementation the resolution of single vs multiple task queues, it in fact may not me germane to the XHR specification. When I follow the implied link from #terminology to the HTML5 draft, I get this: http://www.w3.org/TR/2009/WD-html5-20090825/Overview.html#queue-a-task This section of the HTML5 document itself admits that there may be other implementations of task queues, as in this note: Note: Other specifications can define other event loops; in particular, the Web Workers specification does so. Therefore, it seems like it would be in the best interest of not only HTML5 but also Web Workers (no link) to have XHR efine its requirements, and let them be satisfied by integration with other specifications, HTML5 being a prime case, but Web Workers possibly another, in addition to the usual suspects. In summary, I must say that I don't see any roadblocks to a positive response to the Forms WG comment in question, and it doesn't appear to me that it requires all of the many months of work cited by Ian. Ian's point may be valid for the entireity of the HTML5 document, but for this XHR document to advance to the next stage, it still seems both necessary and possible to resolve the required definitions in a way that makes HTML5 integration almost unchanged, yet leaves open integration with, as Anne aptly puts it, other contexts. Leigh.
RE: XMLHttpRequest Comments from W3C Forms WG
Boris, Thank you for the clarification. Surely then this ought to be fixed with an IETF or W3C document describing this fact, and not by requiring all future specifications which use URLs to reference the HTML5 document. Is it defined in http://www.w3.org/html/wg/href/draft ? If so, perhaps that document needs to have a better title than Web Addresses in HTML5 if it's already in use in user agents in practice in web reality? Thank you, Leigh. -Original Message- From: Boris Zbarsky [mailto:bzbar...@mit.edu] Sent: Thursday, December 17, 2009 2:17 PM To: Klotz, Leigh Cc: WebApps WG; Forms WG Subject: Re: XMLHttpRequest Comments from W3C Forms WG On 12/17/09 2:10 PM, Klotz, Leigh wrote: I'd be surprised if some of these aren't terms already defined elsewhere. URL for example, is surely not given a different definition in HTML5 from the definition in RFC 3986. As it happens, it is. There are various strings that are defined to not be a URL in RFC 3986 terms (as in, don't match the production) but are used on the web in practice and which handling needs to be defined for. In other words, RFC 3986 is pretty well divorced from web reality; a UA trying to actually implement it ends up not compatible with the web. -Boris
Re: XMLHttpRequest Comments from W3C Forms WG
On 12/17/09 2:22 PM, Klotz, Leigh wrote: Thank you for the clarification. Surely then this ought to be fixed with an IETF or W3C document describing this fact After some pushback, there is in fact such a document being worked on. It's not quite far enough to reference normatively last I checked Is it defined in http://www.w3.org/html/wg/href/draft ? Yep. -Boris
RE: XMLHttpRequest Comments from W3C Forms WG
Great! It sounds like more progress is being made on both putting experience from implementations back into specifications, and in modularizing the XHR document references, since it will give a better place than HTML5 for reference. Leigh. -Original Message- From: Boris Zbarsky [mailto:bzbar...@mit.edu] Sent: Thursday, December 17, 2009 2:38 PM To: Klotz, Leigh Cc: WebApps WG; Forms WG Subject: Re: XMLHttpRequest Comments from W3C Forms WG On 12/17/09 2:22 PM, Klotz, Leigh wrote: Thank you for the clarification. Surely then this ought to be fixed with an IETF or W3C document describing this fact After some pushback, there is in fact such a document being worked on. It's not quite far enough to reference normatively last I checked Is it defined in http://www.w3.org/html/wg/href/draft ? Yep. -Boris
Re: XMLHttpRequest Comments from W3C Forms WG
As Ian already has mentioned. No one is disputing that most of these things should be factored out of the HTML5 spec. But so far no one has stepped up to that task. Until someone does we'll have to live with the reality that these things are defined in the HTML5 spec and the HTML5 spec alone. / Jonas On Thu, Dec 17, 2009 at 2:40 PM, Klotz, Leigh leigh.kl...@xerox.com wrote: Great! It sounds like more progress is being made on both putting experience from implementations back into specifications, and in modularizing the XHR document references, since it will give a better place than HTML5 for reference. Leigh. -Original Message- From: Boris Zbarsky [mailto:bzbar...@mit.edu] Sent: Thursday, December 17, 2009 2:38 PM To: Klotz, Leigh Cc: WebApps WG; Forms WG Subject: Re: XMLHttpRequest Comments from W3C Forms WG On 12/17/09 2:22 PM, Klotz, Leigh wrote: Thank you for the clarification. Surely then this ought to be fixed with an IETF or W3C document describing this fact After some pushback, there is in fact such a document being worked on. It's not quite far enough to reference normatively last I checked Is it defined in http://www.w3.org/html/wg/href/draft ? Yep. -Boris
RE: XMLHttpRequest Comments from W3C Forms WG
OK, so is the conclusion that XHR is implementable only in HTML5 and should be re-titled XMLHttpRequest in HTML5 or something similar? -Original Message- From: Jonas Sicking [mailto:jo...@sicking.cc] Sent: Thursday, December 17, 2009 3:14 PM To: Klotz, Leigh Cc: Boris Zbarsky; WebApps WG; Forms WG Subject: Re: XMLHttpRequest Comments from W3C Forms WG As Ian already has mentioned. No one is disputing that most of these things should be factored out of the HTML5 spec. But so far no one has stepped up to that task. Until someone does we'll have to live with the reality that these things are defined in the HTML5 spec and the HTML5 spec alone. / Jonas On Thu, Dec 17, 2009 at 2:40 PM, Klotz, Leigh leigh.kl...@xerox.com wrote: Great! It sounds like more progress is being made on both putting experience from implementations back into specifications, and in modularizing the XHR document references, since it will give a better place than HTML5 for reference. Leigh. -Original Message- From: Boris Zbarsky [mailto:bzbar...@mit.edu] Sent: Thursday, December 17, 2009 2:38 PM To: Klotz, Leigh Cc: WebApps WG; Forms WG Subject: Re: XMLHttpRequest Comments from W3C Forms WG On 12/17/09 2:22 PM, Klotz, Leigh wrote: Thank you for the clarification. Surely then this ought to be fixed with an IETF or W3C document describing this fact After some pushback, there is in fact such a document being worked on. It's not quite far enough to reference normatively last I checked Is it defined in http://www.w3.org/html/wg/href/draft ? Yep. -Boris
Re: XMLHttpRequest Comments from W3C Forms WG
On Dec 17, 2009, at 2:37 PM, Boris Zbarsky wrote: On 12/17/09 2:22 PM, Klotz, Leigh wrote: Thank you for the clarification. Surely then this ought to be fixed with an IETF or W3C document describing this fact After some pushback, there is in fact such a document being worked on. It's not quite far enough to reference normatively last I checked Is it defined in http://www.w3.org/html/wg/href/draft ? Yep. It's expected that at some point soon, all of the necessary rules for processing URLish strings in a Web-compatible way will be defined in the next version of the IRI RFC. Current draft: http://tools.ietf.org/html/draft-duerst-iri-bis-07 . However, not all the necessary definitions are in there yet. We should change our reference to IRIbis when it is ready. Regards, Maciej
Re: XMLHttpRequest Comments from W3C Forms WG
On Dec 17, 2009, at 3:15 PM, Klotz, Leigh wrote: OK, so is the conclusion that XHR is implementable only in HTML5 and should be re-titled XMLHttpRequest in HTML5 or something similar? I think your premise is false, and I don't such a retitling would be helpful. The XHR spec does not require a full implementation of HTML5. It only references some concepts from HTML5. The XHR spec could be implemented in an SVG or HTML4 or XHTML 1.0 implementation that did not support most aspects of HTML5 at all, as long as it could satisfy the requirements implied by those definitions. Your proposed title change would imply that the XHR spec could only be implemented by an HTML5 UA, but that is not accurate. All we have here is a case of suboptimal factoring of the specifications, so that some concepts of very general applicability to the Web platform are presently only defined in HTML5. Some of them are in the process of being broken out, some of them already have been broken out, and more are likely to be broken out in the future. XMLHttpRequest is in fact a pretty good example of factoring something out of HTML5, and even though we haven't cleaned up its whole chain of dependencies, I do not think that is a reason to stuff it back into HTML5, or to block progress on perfecting its dependencies. Regards, Maciej -Original Message- From: Jonas Sicking [mailto:jo...@sicking.cc] Sent: Thursday, December 17, 2009 3:14 PM To: Klotz, Leigh Cc: Boris Zbarsky; WebApps WG; Forms WG Subject: Re: XMLHttpRequest Comments from W3C Forms WG As Ian already has mentioned. No one is disputing that most of these things should be factored out of the HTML5 spec. But so far no one has stepped up to that task. Until someone does we'll have to live with the reality that these things are defined in the HTML5 spec and the HTML5 spec alone. / Jonas On Thu, Dec 17, 2009 at 2:40 PM, Klotz, Leigh leigh.kl...@xerox.com wrote: Great! It sounds like more progress is being made on both putting experience from implementations back into specifications, and in modularizing the XHR document references, since it will give a better place than HTML5 for reference. Leigh. -Original Message- From: Boris Zbarsky [mailto:bzbar...@mit.edu] Sent: Thursday, December 17, 2009 2:38 PM To: Klotz, Leigh Cc: WebApps WG; Forms WG Subject: Re: XMLHttpRequest Comments from W3C Forms WG On 12/17/09 2:22 PM, Klotz, Leigh wrote: Thank you for the clarification. Surely then this ought to be fixed with an IETF or W3C document describing this fact After some pushback, there is in fact such a document being worked on. It's not quite far enough to reference normatively last I checked Is it defined in http://www.w3.org/html/wg/href/draft ? Yep. -Boris
Re: XMLHttpRequest Comments from W3C Forms WG
On Wed, 25 Nov 2009 21:46:59 +0100, Klotz, Leigh leigh.kl...@xerox.com wrote: This comment on XMLHttpRequest [1] is from the Forms WG. A standalone W3C Recommendation-track document is welcome, particularly because of the statement in [2] The goal of this specification is to document a minimum set of interoperable features based on existing implementations, allowing Web developers to use these features without platform-specific code. This goal was widely quoted in web discussion on the working drafts, and is no doubt an attractive feature of a standalone specification document. Note that we changed this goal slightly because documenting the mimimum set of interoperable features did not work very well once you went beyond a certain level of detail. The XMLHttpRequest functionality described in this document has previously been well isolated, and in fact XHR itself has beeen implemented by a number of different desktop browser vendors by copying the original implementations. It appears that the current draft, howevever, has a wide dependence on HTML5: [3] This specification already depends on HTML 5 for other reasons so there is not much additional overhead because of this. This is not new, actually, but alas. That dependence runs counter to the goals of allowing Web developers to use the features without platform-specific code. Why would that be? HTML5 is not platform-specific. While it may be useful for the HTML5 specifications to include XMLHTTPRequest and make enhancements to it, the dependency should be from HTML5 on XMLHttpRequest, and not vice versa. Making XMLHttpRequest depend on HTML5 causes problems with non-HTML5 implementations of the feature. HTML5 is the only specification that defines several core concepts of the Web platform architecture, such as event loops, event handler attributes, etc. In summary, we feel that the dependencies between HTML5 and XMLHttpRequest are in the wrong direction. We ask that the dependency on HTML5 be eliminated, and that the XMLHttpRequest Working Draft be changed to specify minimum requirements for integration in the areas for which it depends on HTML5. The HTML5 document itself can surely satisfy these requirements. I do not think it makes sense that a user agent that implements e.g. HTML5 and SVG would have two implementations of XMLHttpRequest. HTML5 simply defines some core underlying concepts and these will be the same everywhere. There are indeed things that can differ depending on the context and those have been abstracted out, as you found. Mostly to facilitate Web Workers, but I can imagine these hooks might be used elsewhere too. [1] http://www.w3.org/TR/2009/WD-XMLHttpRequest-20091119 [2] http://www.w3.org/TR/2006/WD-XMLHttpRequest-20060405/ [3] http://www.w3.org/TR/2009/WD-XMLHttpRequest-20091119/#dependencies (I corrected the numbering here.) -- Anne van Kesteren http://annevankesteren.nl/
RE: XMLHttpRequest Comments from W3C Forms WG
Anne, Thank you for your corrections and updates. I'd like to suggest that the main issue is dependency of the XHR document on concepts where HTML5 is the only specification that defines several core concepts of the Web platform architecture, such as event loops, event handler attributes, Etc. If this is indeed the case, and the dependency cannot be abstracted out, then XHR must well and truly be considered a part of HTML5. However, since you site SVG as another user of XHR, then it seems that it's still a goal to have XHR not require HTML5. Therefore, even in the light of the changes in details I've cited (and your kind corrections for my errors and outdated imformation), our request that you abstract out the dependencies on HTML5 into a separate document (perhaps part of the HTML5 family, perhaps not) still stands. Thank you, Leigh. -Original Message- From: Anne van Kesteren [mailto:ann...@opera.com] Sent: Wednesday, December 16, 2009 6:54 AM To: Klotz, Leigh; WebApps WG Cc: Forms WG Subject: Re: XMLHttpRequest Comments from W3C Forms WG On Wed, 25 Nov 2009 21:46:59 +0100, Klotz, Leigh leigh.kl...@xerox.com wrote: This comment on XMLHttpRequest [1] is from the Forms WG. A standalone W3C Recommendation-track document is welcome, particularly because of the statement in [2] The goal of this specification is to document a minimum set of interoperable features based on existing implementations, allowing Web developers to use these features without platform-specific code. This goal was widely quoted in web discussion on the working drafts, and is no doubt an attractive feature of a standalone specification document. Note that we changed this goal slightly because documenting the mimimum set of interoperable features did not work very well once you went beyond a certain level of detail. The XMLHttpRequest functionality described in this document has previously been well isolated, and in fact XHR itself has beeen implemented by a number of different desktop browser vendors by copying the original implementations. It appears that the current draft, howevever, has a wide dependence on HTML5: [3] This specification already depends on HTML 5 for other reasons so there is not much additional overhead because of this. This is not new, actually, but alas. That dependence runs counter to the goals of allowing Web developers to use the features without platform-specific code. Why would that be? HTML5 is not platform-specific. While it may be useful for the HTML5 specifications to include XMLHTTPRequest and make enhancements to it, the dependency should be from HTML5 on XMLHttpRequest, and not vice versa. Making XMLHttpRequest depend on HTML5 causes problems with non-HTML5 implementations of the feature. HTML5 is the only specification that defines several core concepts of the Web platform architecture, such as event loops, event handler attributes, etc. In summary, we feel that the dependencies between HTML5 and XMLHttpRequest are in the wrong direction. We ask that the dependency on HTML5 be eliminated, and that the XMLHttpRequest Working Draft be changed to specify minimum requirements for integration in the areas for which it depends on HTML5. The HTML5 document itself can surely satisfy these requirements. I do not think it makes sense that a user agent that implements e.g. HTML5 and SVG would have two implementations of XMLHttpRequest. HTML5 simply defines some core underlying concepts and these will be the same everywhere. There are indeed things that can differ depending on the context and those have been abstracted out, as you found. Mostly to facilitate Web Workers, but I can imagine these hooks might be used elsewhere too. [1] http://www.w3.org/TR/2009/WD-XMLHttpRequest-20091119 [2] http://www.w3.org/TR/2006/WD-XMLHttpRequest-20060405/ [3] http://www.w3.org/TR/2009/WD-XMLHttpRequest-20091119/#dependencies (I corrected the numbering here.) -- Anne van Kesteren http://annevankesteren.nl/
RE: XMLHttpRequest Comments from W3C Forms WG
I'll take this as a No and we'll discuss it in the Forms WG next year when we pick up again. Happy Holidays, Ian, Anne, and all. Leigh. -Original Message- From: Ian Hickson [mailto:i...@hixie.ch] Sent: Wednesday, December 16, 2009 11:54 AM To: Klotz, Leigh Cc: Anne van Kesteren; WebApps WG; Forms WG Subject: RE: XMLHttpRequest Comments from W3C Forms WG On Wed, 16 Dec 2009, Klotz, Leigh wrote: Therefore, even in the light of the changes in details I've cited (and your kind corrections for my errors and outdated imformation), our request that you abstract out the dependencies on HTML5 into a separate document (perhaps part of the HTML5 family, perhaps not) still stands. This would be a colossal amount of work, for which we unfortunately do not have any volunteers. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
RE: XMLHttpRequest Comments from W3C Forms WG
If this is the case, it shouldn't be too much work then to take out the parts that don't need to be implemented and put them into a separate, rec-track document entitled roughly XHR for HTML5. Leigh. -Original Message- From: Jonas Sicking [mailto:jo...@sicking.cc] Sent: Wednesday, December 16, 2009 12:04 PM To: Klotz, Leigh Cc: Ian Hickson; Anne van Kesteren; WebApps WG; Forms WG Subject: Re: XMLHttpRequest Comments from W3C Forms WG Note that just referring to a few specific concepts defined in HTML5 does not force anyone to implement the rest of HTML5. As things stand right now it's quite possible to implement XMLHttpRequest according to spec, without implementing almost anything in the HTML5 spec. Put it another way, abstracting out these concepts from the HTML5 spec would on a technical level not change what anyone would need to implement. / Jonas On Wed, Dec 16, 2009 at 11:56 AM, Klotz, Leigh leigh.kl...@xerox.com wrote: I'll take this as a No and we'll discuss it in the Forms WG next year when we pick up again. Happy Holidays, Ian, Anne, and all. Leigh. -Original Message- From: Ian Hickson [mailto:i...@hixie.ch] Sent: Wednesday, December 16, 2009 11:54 AM To: Klotz, Leigh Cc: Anne van Kesteren; WebApps WG; Forms WG Subject: RE: XMLHttpRequest Comments from W3C Forms WG On Wed, 16 Dec 2009, Klotz, Leigh wrote: Therefore, even in the light of the changes in details I've cited (and your kind corrections for my errors and outdated imformation), our request that you abstract out the dependencies on HTML5 into a separate document (perhaps part of the HTML5 family, perhaps not) still stands. This would be a colossal amount of work, for which we unfortunately do not have any volunteers. -- Ian Hickson U+1047E )\._.,--,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
RE: XMLHttpRequest Comments from W3C Forms WG
On Wed, 16 Dec 2009, Klotz, Leigh wrote: Therefore, even in the light of the changes in details I've cited (and your kind corrections for my errors and outdated imformation), our request that you abstract out the dependencies on HTML5 into a separate document (perhaps part of the HTML5 family, perhaps not) still stands. This would be a colossal amount of work, for which we unfortunately do not have any volunteers. I'll take this as a No and we'll discuss it in the Forms WG next year when we pick up again. FWIW, there is a general agreement that this would be an ideal thing to do; it really does boil down to lack of manpower. We did try at one point to do it, but the effort floundered. If you know of anyone who would be knowedgable enough to edit such a draft, and who would have the time to do it, please do let us know. I would be happy to help someone get started on this. I estimated in 2008 that someone with the suitable skills would face the following workload: | - 4 months at 40h/week extracting existing text from HTML5 | - 12 months at 40h/week reverse-engineering and specifying | - 12 months at 40h/week responding to feedback | - 24 months at 5h/week responding to feedback -- http://lists.w3.org/Archives/Public/public-html/2008Oct/0127.html (#10) Some of that is reduced now, since some progress has been made on the relevant material, but it'd still probably be in the same ballpark. Happy Holidays, Ian, Anne, and all. Likewise. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
RE: XMLHttpRequest Comments from W3C Forms WG
Thank you. It does seem like a daunting amount of effort, and I hope it doesn't cause the XHR draft to be derailed. Things that are impossible just take longer ;-) Leigh. -Original Message- From: Ian Hickson [mailto:i...@hixie.ch] Sent: Wednesday, December 16, 2009 12:13 PM To: Klotz, Leigh Cc: Anne van Kesteren; WebApps WG; Forms WG Subject: RE: XMLHttpRequest Comments from W3C Forms WG On Wed, 16 Dec 2009, Klotz, Leigh wrote: Therefore, even in the light of the changes in details I've cited (and your kind corrections for my errors and outdated imformation), our request that you abstract out the dependencies on HTML5 into a separate document (perhaps part of the HTML5 family, perhaps not) still stands. This would be a colossal amount of work, for which we unfortunately do not have any volunteers. I'll take this as a No and we'll discuss it in the Forms WG next year when we pick up again. FWIW, there is a general agreement that this would be an ideal thing to do; it really does boil down to lack of manpower. We did try at one point to do it, but the effort floundered. If you know of anyone who would be knowedgable enough to edit such a draft, and who would have the time to do it, please do let us know. I would be happy to help someone get started on this. I estimated in 2008 that someone with the suitable skills would face the following workload: | - 4 months at 40h/week extracting existing text from HTML5 | - 12 months at 40h/week reverse-engineering and specifying | - 12 months at 40h/week responding to feedback | - 24 months at 5h/week responding to feedback -- http://lists.w3.org/Archives/Public/public-html/2008Oct/0127.html (#10) Some of that is reduced now, since some progress has been made on the relevant material, but it'd still probably be in the same ballpark. Happy Holidays, Ian, Anne, and all. Likewise. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: XMLHttpRequest Comments from W3C Forms WG
On 11/25/09 3:46 PM, Klotz, Leigh wrote: The XMLHttpRequest functionality described in this document has previously been well isolated, and in fact XHR itself has beeen implemented by a number of different desktop browser vendors by copying the original implementations. Note that these were all building on a common reverse-engineered base, and that the implementations were far from interoperable. In summary, we feel that the dependencies between HTML5 and XMLHttpRequest are in the wrong direction. We ask that the dependency on HTML5 be eliminated The main dependencies, I believe, are on the Window object and the security sandboxing behavior that web browsers have. How do you propose such dependencies be eliminated? and that the XMLHttpRequest Working Draft be changed to specify minimum requirements for integration in the areas for which it depends on HTML5. The XHR spec needs to describe the precise behavior of things like same-origin requests. However nothing specifies the concept of origins outside the HTML5 specification. Should XHR simply say that something else needs to define origins, in this situation, without referring to the one thing that actually does define them? There are no plans for anyone other than HTML5 to define them at this point, and the HTML5 definition is not limited to HTML documents. -Boris
RE: XMLHttpRequest Comments from W3C Forms WG
Boris, Thank you for your response. I appreciate your asking the clarifying questions. I'll put some answers inline below. Please consider these answers to be part of the Forms WG comment as well. Leigh. -Original Message- From: Boris Zbarsky [mailto:bzbar...@mit.edu] Sent: Wednesday, November 25, 2009 12:54 PM To: Klotz, Leigh Cc: public-webapps@w3.org; Forms WG Subject: Re: XMLHttpRequest Comments from W3C Forms WG On 11/25/09 3:46 PM, Klotz, Leigh wrote: The XMLHttpRequest functionality described in this document has previously been well isolated, and in fact XHR itself has beeen implemented by a number of different desktop browser vendors by copying the original implementations. Note that these were all building on a common reverse-engineered base, and that the implementations were far from interoperable. Indeed, a standalone XHR specification document is welcome, and interoperability is weakened if it works only in HTML5. In summary, we feel that the dependencies between HTML5 and XMLHttpRequest are in the wrong direction. We ask that the dependency on HTML5 be eliminated The main dependencies, I believe, are on the Window object and the security sandboxing behavior that web browsers have. How do you propose such dependencies be eliminated? The majority of the current WD is well modularized and isolated. These points are integration points for XHR and other environments. One important target of integration is HTML5, but it is not the only one. Forgive me if I sound like I'm lecturing, but I'd just like to state this point about abstraction for the archives: a small piece of modular functionality which needs to be integrated into a larger system should specify its integration points and the requirements it has for support from the larger system. That's what we mean by minimum requirements below. So, to be concrete in an example dependency, if the window object is important to XHR, then its dependencies should be abstracted out. It's unfortunate that the WD notes that a previous effort at providing a Window Object specification cannot be used, but it is still better for XHR to specify its requirements and let them be by its integrators, whether they be HTML5, a revivified Window Object 1.0, or some other context. For example, section 4.1 Base and Origin URL says This specification defines their values when the global object is represented by the Window object. When the XMLHttpRequest object used in other contexts their values will have to be defined as appropriate for that context. That is considered to be out of scope for this specification. Our point is that the XHR document should merely state its requirements for such facilities (base and origin) and that the HTML5 specification document should say how it satisfies them. Alternatively, a companion document called XMLHttpRequest for HTML5 could specfiy it, but that's a detail of integration best left to the HTML5 WG. In summary, we ask that the XHR document define its requirements, and that the integration with HTML5 satisfy them. I realize that there are other dependencies on HTML5 in the XHR document, but I would like to agree at first on the principle that specifications which incorporate XHR should depend on it, and not vice versa. (I won't specifically address the last question below, because I believe it's been answered sufficiently above.) Leigh. and that the XMLHttpRequest Working Draft be changed to specify minimum requirements for integration in the areas for which it depends on HTML5. The XHR spec needs to describe the precise behavior of things like same-origin requests. However nothing specifies the concept of origins outside the HTML5 specification. Should XHR simply say that something else needs to define origins, in this situation, without referring to the one thing that actually does define them? There are no plans for anyone other than HTML5 to define them at this point, and the HTML5 definition is not limited to HTML documents. -Boris Thank you, Leigh.
RE: XMLHttpRequest Comments from W3C Forms WG
Please note (for the record) the following reference from public-webapps on this topic before. (The lists.w3.org archives seem to be stuck in 2008.) http://article.gmane.org/gmane.org.w3c.appformats/8012 Leigh. -Original Message- From: public-forms-requ...@w3.org [mailto:public-forms-requ...@w3.org] On Behalf Of Klotz, Leigh Sent: Wednesday, November 25, 2009 1:27 PM To: Boris Zbarsky Cc: public-webapps@w3.org; Forms WG Subject: RE: XMLHttpRequest Comments from W3C Forms WG Boris, Thank you for your response. I appreciate your asking the clarifying questions. I'll put some answers inline below. Please consider these answers to be part of the Forms WG comment as well. Leigh. -Original Message- From: Boris Zbarsky [mailto:bzbar...@mit.edu] Sent: Wednesday, November 25, 2009 12:54 PM To: Klotz, Leigh Cc: public-webapps@w3.org; Forms WG Subject: Re: XMLHttpRequest Comments from W3C Forms WG On 11/25/09 3:46 PM, Klotz, Leigh wrote: The XMLHttpRequest functionality described in this document has previously been well isolated, and in fact XHR itself has beeen implemented by a number of different desktop browser vendors by copying the original implementations. Note that these were all building on a common reverse-engineered base, and that the implementations were far from interoperable. Indeed, a standalone XHR specification document is welcome, and interoperability is weakened if it works only in HTML5. In summary, we feel that the dependencies between HTML5 and XMLHttpRequest are in the wrong direction. We ask that the dependency on HTML5 be eliminated The main dependencies, I believe, are on the Window object and the security sandboxing behavior that web browsers have. How do you propose such dependencies be eliminated? The majority of the current WD is well modularized and isolated. These points are integration points for XHR and other environments. One important target of integration is HTML5, but it is not the only one. Forgive me if I sound like I'm lecturing, but I'd just like to state this point about abstraction for the archives: a small piece of modular functionality which needs to be integrated into a larger system should specify its integration points and the requirements it has for support from the larger system. That's what we mean by minimum requirements below. So, to be concrete in an example dependency, if the window object is important to XHR, then its dependencies should be abstracted out. It's unfortunate that the WD notes that a previous effort at providing a Window Object specification cannot be used, but it is still better for XHR to specify its requirements and let them be by its integrators, whether they be HTML5, a revivified Window Object 1.0, or some other context. For example, section 4.1 Base and Origin URL says This specification defines their values when the global object is represented by the Window object. When the XMLHttpRequest object used in other contexts their values will have to be defined as appropriate for that context. That is considered to be out of scope for this specification. Our point is that the XHR document should merely state its requirements for such facilities (base and origin) and that the HTML5 specification document should say how it satisfies them. Alternatively, a companion document called XMLHttpRequest for HTML5 could specfiy it, but that's a detail of integration best left to the HTML5 WG. In summary, we ask that the XHR document define its requirements, and that the integration with HTML5 satisfy them. I realize that there are other dependencies on HTML5 in the XHR document, but I would like to agree at first on the principle that specifications which incorporate XHR should depend on it, and not vice versa. (I won't specifically address the last question below, because I believe it's been answered sufficiently above.) Leigh. and that the XMLHttpRequest Working Draft be changed to specify minimum requirements for integration in the areas for which it depends on HTML5. The XHR spec needs to describe the precise behavior of things like same-origin requests. However nothing specifies the concept of origins outside the HTML5 specification. Should XHR simply say that something else needs to define origins, in this situation, without referring to the one thing that actually does define them? There are no plans for anyone other than HTML5 to define them at this point, and the HTML5 definition is not limited to HTML documents. -Boris Thank you, Leigh.
