sXBL and XBL2 (was: Moving past last call for HTML5)

Hi, Ian-

Ian Hickson wrote (on 2/20/09 9:28 PM):
>
> I speak from the position of the person who represented the browser
> vendors on the sXBL conference calls, where two parties had radically
> different needs and in the interest of progress, one party (the browser
> vendors) kept agreeing to compromises because it would help move the spec
> forward. The result was that the spec became less and less like what the
> people I was representing wanted, until we finally reached something that
> we weren't willing to compromise on, and then the process collapsed. The
> result was that we then took the spec onto another track and changed
> almost every compromise back to what we originally wanted, with XBL2
> resulting. I have no interest in seeing a specification go down this same
> road again, with some parties compromising on issue after issue (_whoever_
> that might be), if it isn't clear that there is a light at the end of the
> tunnel where _all_ the parties are getting something for their efforts.

It's a shame that the email list for that particular spec (sXBL) is 
Member-confidential, because it stops the general public from being able 
to review the discussions and make a judgment for themselves whether the 
straw-poll that broke the camel's back was as dramatic as you represent.

I was not part of the SVG WG at the time (indeed, I was not active in 
W3C except peripherally), but my subsequent reading of that mailing 
list, and my received wisdom from the active participants at the time, 
does not jibe with your characterization.  In particular, you may be 
overstating how closely you represented the browser vendors.  (For the 
benefit of those who have Member access, I refer to the email that leads 
me to that conclusion [1]; for those that don't have Member access, I 
apologize for including the link, and for my circumspect assertion.)

 From my perspective at the time, as a content developer, I was already 
writing content for the previous incarnation of sXBL, RCC (Rendering 
Custom Content), which itself was derived from RAX (Rendering Arbitrary 
XML).  This was extremely powerful and useful, and it was implemented 
(albeit with warts) in v6pr1 of Adobe's SVG Viewer.  Many of us in the 
SVG development community were fully expecting this (or some variant of 
it) to make it to Rec, and for it to be deployed soon.  We were 
disappointed that it ran aground, and was not resurrected until 2 years 
later, as a spec that did not cover the same functionality. [2]

At the time of XBL2, I requested that XPath be allowed as an alternative 
to CSS Selectors, since both seem to be implemented in the set of 
browsers that were likely to implement XBL2. [3]  I'm still not 
satisfied that it is not an option.

As I understand it, no browser has yet implemented XBL2 (though I do 
understand Mozilla intends to do so soon).  This is 4 years after sXBL, 
and 5 or more years after I was writing content for the existing RCC 
implementation.  I agree that the outcome of that work was 
unsatisfactory by any measure, not least because of the protracted gap 
in Web developers' toolkits.  In that time, the relatively minor issue 
that you say was a bridge too far could have been sorted out by 
implementing extensions to sXBL and proving the case in code rather than 
in rhetoric.  A logical successor to sXBL, with implementation 
experience backing it up, could have been a Rec by now, with developers 
and users already having 4 or 5 years of sXBL content.

How are we meant to draw from this the lesson that compromise is bad?


[1] (Member-confidential) 
http://lists.w3.org/Archives/Member/member-binding-tf/2005JulSep/0075.html
[2] http://www.w3.org/TR/xbl/
[3] http://www-xray.ast.cam.ac.uk/~jgraham/mozilla/xpath-tutorial.html

Regards-
-Doug Schepers
W3C Team Contact, SVG and WebApps WGs

Received on Wednesday, 25 February 2009 10:09:28 UTC