XBL2 CR and the Sept 2010 version of XBL [Was: Re: Comments on proposed editor's draft of XBL2 from Forms WG]
Hi All, In case you haven't followed this thread (started at [HEAD]), my extremely short summary is: 1. Hixie, based on discussions with David Hyatt, Tab Atkins and perhaps some others, created a new Editor's Draft (ED) of XBL2 [XBL-Sep-2010] that defines the XBL language as part of HTML (rather than defining its own namespace) and removes a number of XBL2 features to lower the initial implementation cost, so that we can get some traction, and then we can add the features back in afterwards to get it back to where we were before (Hixie). (See [DIFFS] for a summary of the changes.) 2. The Forms community would like to see XBL2 - as defined in the 2007 CR [XBL2-CR] - continued, since Leigh noted XBL2 is being used by XForms implementators and XForms users at the authoring level. (See [LEIGH] for details.) Ideally, the W3C would only progress one Binding Language on the Recommendation track. However, given the implementations by the Forms community and some Browser vendors not implementing the XBL2 CR because of the reasons Hixie mentioned, a single spec may not be able to satisfy all interests. As such, perhaps a way forward is to: a. Keep the XBL2 CR on the REC track and put the burden of satisfying the CR exit criteria (e.g. test suite creation) on those that support it; and b. Assuming there is reasonable interest in implementing the Sep 2010 ED of XBL, push it as a new spec on the REC track (i.e. something with a shortname other than xbl). [At the risk of ratholing on names, Web XBL is an option as is Web BL since (as Leigh pointed out), there is no XML in [XBL-Sep-2010].] Would the [XBL2-CR] proponents please provide their level of interest in moving that spec forward? In particular, are you willing to create the test suite necessary to exit CR? Would the [XBL-Sep-2010] proponents indicate their level of interest in moving that ED forward, in particular, information about implementation plans? Feedback, as always, is welcome. -Art Barstow [HEAD] http://lists.w3.org/Archives/Public/public-webapps/2010JulSep/0675.html [XBL-Sep-2010] http://dev.w3.org/2006/xbl2/ [XBL2-CR] http://www.w3.org/TR/2007/CR-xbl-20070316/ [LEIGH] http://lists.w3.org/Archives/Public/public-webapps/2010JulSep/1008.html [DIFFS] http://dev.w3.org/2006/xbl2/Overview.html#editors-note
Re: Comments on proposed editor's draft of XBL2 from Forms WG
Perhaps HTML Components (HTC) would be a more accurate name now. On 23/09/10 12:53 PM, Adam Barth wrote: Perhaps the new effort should be called XBL3? Adam On Wed, Sep 22, 2010 at 9:30 AM, Leigh L. Klotz, Jr. leigh.kl...@xerox.com wrote:
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
Re: Comments on proposed editor's draft of XBL2 from Forms WG
On Wed, 22 Sep 2010, Leigh L. Klotz, Jr. wrote: We applaud the desire of the HTML5 WG to incorporate aspects of XBL into HTML5. The recent changes were just some edits I did on a whim, it isn't a work product of a W3C working group and does not represent any working group's desires or requirements. 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. Are there implementations of XBL2? If not, keeping the draft doesn't seem particularly interesting. (Note that Mozilla's implementation of XBL, which long predates any XBL2 work, has less in common with XBL2 than does the most recent editor's draft with the dramatic changes.) 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. Since the variants of XBL2 implemented here are not what the XBL2 draft says (and are not mutually interoperable), the XBL2 draft doesn't seem particularly useful for these products. If people are interested in pursuing convergence for those implementations, or if people are interested in providing documentation to allow other implementations to interoperably implement the same technology as Orbeon or Xerox, then work would first have to occur to write a specification that actually describes those implementations. If anyone would like to do this work, the XBL2 specification is available as a base under either the W3C copyright, if the work is to happen at the W3C, or under a Creative Commons license at mozilla.org, if the work is to happen elsewhere. Personally my only goal with XBL is to see it implemented in Web browsers; interoperable Web browser implementations is the only criteria of success that I intend to apply to the development of this draft. I intend to continue editing the draft until it is in a form that browsers are willing to implement, or until it is clear that the changes that would be required to reach this state would result in the technology being uninteresting. Implementations outside of the Web are fine too, of course, but are not especially relevant in terms of the goal of obtaining interoperable Web browser implementations. HTH, -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
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: Comments on proposed editor's draft of XBL2 from Forms WG
Perhaps the new effort should be called XBL3? Adam On Wed, Sep 22, 2010 at 9:30 AM, Leigh L. Klotz, Jr. leigh.kl...@xerox.com wrote: 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