- From: Klotz, Leigh <Leigh.Klotz@xerox.com>
- Date: Wed, 22 Sep 2010 16:53:18 -0700
- To: <public-webapps@w3.org>
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, dropped<style> and<script> in favour of HTML equivalents, dropped all the<handler> 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] http://lists.w3.org/Archives/Public/public-forms/2010Sep/att-0026/2010-0 9-15.html#topic11 [Firefox Custom Controls Examples] https://developer.mozilla.org/en/XForms/Custom_Controls_Examples https://developer.mozilla.org/en/XForms/Custom_Controls [Orbeon] http://wiki.orbeon.com/forms/doc/developer-guide/xbl-components-guide No browser support is required. [Xerox] At present, this is work in development for product release, but works with XSLT, XProc, and the AgenceXML XSLTForms XForms processor. No browser support is required. [XForms Wikibook Custom Controls] http://en.wikibooks.org/wiki/XForms/Custom_Controls [XSLTForms] http://www.agencexml.com [Ubiquity XForms] http://code.google.com/p/ubiquity-xforms/ [Web Backplane] http://webbackplane.com/ Leigh L. Klotz, Jr. Co-Chair W3C Forms Working Group Xerox Corp.
Received on Wednesday, 22 September 2010 23:53:54 UTC