Re: Last call comments on XML Binding Language (XBL) 2.0

On Wed, 21 Feb 2007, Robin Berjon wrote:
> 
> Put it this way: if XBL is supposedly only useful in the context of a UA 
> that already knows everything there is to know about it, why bother even 
> using XML? It brings in all manners of other constraints that one could 
> happily do without.

Indeed. I've already received requests from various people to make an 
"HTML5" version of XBL that has its own custom format and custom parser 
with defined error handling instead of using XML. The main reason for not 
doing it is that a custom parser is a high implementation burden and a 
high specification burden -- having written the HTML5 parsing algorithm, I 
have no intention of doing it again if I can avoid it.

However, this doesn't apply to xml:id, since the implementation burden for 
supporting 'id' instead of 'xml:id' is negligible (and even possibly 
lower, since you don't have to worry about what happens if someone sets 
'xml:id' on an element in SVG, HTML, or MathML and thus gives an element 
_two_ IDs), and the specification burden is about one line of prose.


> Using [xml:id] costs nothing, and gives the difference between being 
> able to just reuse XBL in all manners of CMSs, document management, or 
> publishing systems on the Web just like that, or having to teach them 
> all about something new.

I'm utterly baffled by this. How exactly would xml:id allow you to 
magically reuse XBL in those contexts? What exactly are you expecting to 
do with XBL that simply changing 'id' to 'xml:id' is going to be a 
panacea?


> Given that the cost of using xml:id is zero, the trade-off is quite 
> simple to all those who don't have a religion that prevents them from 
> adopting things that the CSS WG has been accused of not doing. Its 
> adoption is obvious to the technological atheists.

The cost is not zero. The cost is not high, I grant you. However it is not 
zero. Increased author confusion (why does it work in HTML and not XBL?), 
increased spec cost (referring to another spec, having to ensure that 
error handling that xml:id doesn't define it actually defined in XBL, 
coordinating with other users of xml:id to make sure implementation 
requirements are consistent), increased implementation cost (having to 
handle multiple IDs per node, having to check a namespace and an attribute 
name instead of just checking an unnamespaced attribute). It is a minor 
cost, but it is a cost nonetheless, and an easily avoided one.


You didn't answer my question: why would this single feature be worthy of 
discoverability when the entire rest of the XBL processing model requires 
the UA to have built-in knowledge? Why is IDness in XBL special? Can you 
give actual realistic use cases showing that xml:id is worth it?

xml:id is not being singled out here. We also haven't used XLink, not do 
we have a DTD, nor did we reuse <html:div> (XBL2 has its own <div>), and 
so on. Reuse has its benefits, but it also has its costs. When designing a 
language you have to justify the costs, and I can't justify xml:id.



> > I have marked your request as a potential formal objection.
> 
> And one it will be.

Ok. I have marked it as a formal objection.

Cheers,
-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Received on Wednesday, 21 February 2007 23:28:11 UTC