Re: Comments on proposed editor's draft of XBL2 from Forms WG
On Sep 22, 2010, at 4:53 PM, Klotz, Leigh wrote: We applaud the desire of the HTML5 WG to incorporate aspects of XBL into HTML5. Even if it is reduced from XBL and XBL2, having such facilities in HTML5 will still help others using layered implementation technology of which HTML5 is one part (viz. [Ubiquity XForms], [Web Backplane], [XSLTForms]). For the record, the HTML WG is not involved in the publication of any version of XBL and there are no plans for the HTML WG to do so at this time. It remains a Web Apps WG deliverable, and no one has suggested moving it over. The design of HTML5 does allow for separate specifications to extend it, and we are happy to have such specifications developed by other W3C Working Groups where appropriate, and with sufficient coordination and cross-review. Also, while it is true that HTML5 is our primary charter deliverable, our name is spelled HTML WG, not HTML5 WG. Regards, Maciej Stachowiak W3C HTML Working Group Co-Chair Maciej, Thank you for the corrections and updates, and I apologize for the typo! At one point I said XForms instead of XBL in my earlier message, so you can rest assured I'm an equal-opportunity mis-typist! (Also, I wish to apologize to Art Barstow and the rest of the group for the duplicate message; someone the first one I sent didn't arrive, and once I re-sent it, both appeared in the archives. Perhaps the list server is simply busy.) I would like to ask, though, if your statement as WG Co-Chair that the HTML WG is not involved in XBL and that nobody has suggested moving it over means that we won't be seeing the merge ... with the HTML spec that Ian Hixson, editor of the HTML5 document, indicates he's planning in [1]? Or perhaps is this an issue of current discussion in your WG? I noticed some follow-on comments on webapps debating HTC and other names for XBL in HTML5, and while the Forms WG has no formal comment in that area, we did discuss in the Forms WG the advantages that several XfForms+XHTML implenentations have taken of HTC and Mozilla XBL in the internals of their implementations, and so speaking personally, I want to re-iterate that I think that work on HTML5 in this area would be greatly beneficial to all, no matter what the name is, as long as it isn't predicated on the demise of the XBL2 Recommendation-track document which is currently being used by XForms implementators and XForms users at the authoring level. [1] http://lists.w3.org/Archives/Public/public-forms/2010Sep/0005.html Leigh.
Comments on proposed editor's draft of XBL2 from Forms WG
A version of this message was previously sent by W3C Team request to a members-only list. At Art Barstow's request, I am sending the message to public-webapps, with all members-only content removed and all technical comments preserved. I have also corrected one typo, where XForms was typed in place of XBL. This message is in response to http://lists.w3.org/Archives/Public/public-forms/2010Sep/0005.html which reads in part Since XBL2 wasn't getting much traction, I've taken an axe to the spec and made a number of changes to the spec based on some discussions with some browser vendors: ... The main changes are simplification: I've dropped namespace support, made it part of HTML rather than its own language, droppedstyle andscript in favour of HTML equivalents, dropped all thehandler syntactic sugar (and redirected event forwarding to internal object instead), dropped preload, dropped mentions of XForms and XML Events, and so on. As co-chair of the W3C Forms WG and representative to that group from Xerox, I have been directed [W3C Forms WG Direction] to write the following comments to HCG: XBL is a successful component technology which allows declarative markup to be bound to implementations, and allows the implementations themselves to recursively consist of declarative and eventually imperative and user-agent-specific components. It thus provides for declarative expressive power while still retaining the unobtrusive aspects of separate implementation. One widely-deployed implementation of XBL is in Firefox. XBL in Firefox is widely used, but is non-standard. XBL2 is an attempt to standardize XBL. We applaud the desire of the HTML5 WG to incorporate aspects of XBL into HTML5. Even if it is reduced from XBL and XBL2, having such facilities in HTML5 will still help others using layered implementation technology of which HTML5 is one part (viz. [Ubiquity XForms], [Web Backplane], [XSLTForms]). One of the benefits of a W3C Recommendation is that the technology thus developed can have uses beyond its initial crucible. For example, at least two XForms implementations make use of XBL, and a third shows that it can be used alongside. In these cases, XBL is used to develop components and custom controls for XHTML, some using XForms but some not. We applaud the desire of the HTML5 WG to incorporate aspects of XBL into HTML, we ask that the HTML5 WG implement their own profile of XBL, and the XBL2 Rec-track document not be changed to include the proposed editor's changes removing XML namespaces, XML events, and other XML features from the XBL2. Uses of XBL in XForms and XHTML+XForms: 1. The XForms Wikibook [XForms Wikibook Custom Controls] community documentation shows a number of use cases for custom and aggregate controls with XHTML+XForms, most of which center around the Firefox implementation, but additional work is currently being done for other implementations such as Orbeon. 2. Mozilla Firefox [Firefox Custom Controls] documents how to write custom controls using Mozilla XBL. Additionally, much of the Mozilla XForms XPI itself is implemented using Mozilla's XBL. Namespace and other support is already present in XBL in Firefox; tetaining it in XBL2 would make it easier for such component technologies to be implemented cross-browser. 3. Orbeon uses a profile of XBL2 [Orbeon] to create components in their XHTML+XForms product. Their use case requires namespace support. They have a few additions to XBL2, notably parameters. Orbeon has indicated they have a number of concerns about some of the details of XBL2, and that they are additionally not using all of it. However, the parts they are using are the parts that the proposed editor's draft removes. 4. Xerox also uses a similar profile of XBL2 [Xerox], though somewhat reduced in features from Orbeon's implementation. Xerox uses XBL2 as a transformation step in an XProc-like pipeline to instantiate complex controls in XHTML, both with and without XForms. Xerox uses the parameter mechanism designed by Orbeon, but the implementation is different. In summary, please note that XBL technology has been in use as glue inside browsers for implementing XForms, has been in use in such browsers for components and extensions, and is also used for components in XHTML and XHTML+XForms implementations that have no internal use of XBL. Retaining XBL2 as a Rec-track document is important for the Forms WG, because it can be used along with XForms, just as can XSLT and XProc, to great advantage. Incorporating aspects of XBL into HTML5 is laudable, and we do not wish to hinder it, though we do point out that XML Event support is merely syntax for DOM Events, and that Namespace support is already present for XBL in browsers, so it would not seem that removing either is motivated by practical concerns. References: [W3C Forms WG Direction]
Re: Comments on proposed editor's draft of XBL2 from Forms WG
Additionally, I would like to point out Robin Cover's XML Cover Pages newsletter from OASIS today cites this paper, which shows usage of XBL and XForms: http://xml.coverpages.org/newsletter/news2010-09-21.html http://journal.code4lib.org/articles/3916 Leigh.
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
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
-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
-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
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
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
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. `._.-(,_..'--(,_..'`-.;.'
XMLHttpRequest Comments from W3C Forms WG
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. 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. That dependence runs counter to the goals of allowing Web developers to use the features without platform-specific code. 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. 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. Thank you, Leigh L. Klotz, Jr. Senior Software Architect On behalf of W3C Forms WG [1] http://www.w3.org/TR/2009/WD-XMLHttpRequest-20091119 [1] http://www.w3.org/TR/2006/WD-XMLHttpRequest-20060405/ [2] http://www.w3.org/TR/2009/WD-XMLHttpRequest-20091119/#dependencies -Original Message- From: public-forms-requ...@w3.org [mailto:public-forms-requ...@w3.org] On Behalf Of Steven Pemberton Sent: Thursday, November 19, 2009 8:41 AM To: Forms WG Subject: Fwd: TransAnn: LCWD for XMLHttpRequest; comment deadline 15 December --- Forwarded message --- From: Arthur Barstow art.bars...@nokia.com To: cha...@w3.org, Sam Ruby ru...@intertwingly.net, Maciej Stachowiak m...@apple.com, Paul Cotton paul.cot...@microsoft.com Cc: Subject: TransAnn: LCWD for XMLHttpRequest; comment deadline 15 December Date: Thu, 19 Nov 2009 17:08:32 +0100 This is the Transition Announcement for the 19 November 2009 LCWD of WebApps' XMLHttpRequest spec: http://www.w3.org/TR/2009/WD-XMLHttpRequest-20091119/ The deadline for comments is 15 December. If you have any comments, please send them to: public-webapps@w3.org WGs we identified to review: HTML WG. Comments from all other WGs are welcome and encouraged. -Art Barstow
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.
