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-09-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.
