XBL2 CR and the Sept 2010 version of XBL [Was: Re: Comments on proposed editor's draft of XBL2 from Forms WG]

2010-10-07 Thread Arthur Barstow

 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

2010-09-23 Thread Sean Hogan

 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

2010-09-23 Thread Maciej Stachowiak

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

2010-09-23 Thread Ian Hickson
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

2010-09-23 Thread Klotz, Leigh
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

2010-09-22 Thread Klotz, Leigh
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

2010-09-22 Thread Klotz, Leigh
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

2010-09-22 Thread Adam Barth
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