W3C home > Mailing lists > Public > public-appformats@w3.org > June 2006

Re: XBL 2 and xml:id

From: Ian Hickson <ian@hixie.ch>
Date: Tue, 27 Jun 2006 19:08:10 +0000 (UTC)
To: Robin Berjon <robin.berjon@expway.fr>
Cc: public-appformats@w3.org
Message-ID: <Pine.LNX.4.62.0606271858060.4826@dhalsim.dreamhost.com>

On Tue, 27 Jun 2006, Robin Berjon wrote:
>>>
>>> [we should use xml:id instead of id]
> 
> Would you mind taking the time to explain what about the above position is:
> 
>  a) impractical

Requiring XBL2 to use xml:id instead of its own id attribute is 
impractical because:

It requires implementations to support two specs instead of one.
It requires authors to understand two specs instead of one.
It requires authors to type "xml:id" every time they could have typed "id".
It requires authors to understand that in HTML and SVG it's "id" but in 
XBL it's "xml:id".
It requires authors to understand that while ".id" in the DOM maps to 
"id" in HTML, it maps to "xml:id" in XBL.
It requires authors to understand why they can use xml:id on XBL but not 
on HTML, or, if implementations support both in HTML, why in HTML they can 
have two IDs but they can only have one in XBL.
It requires core DOM accesses to use the namespaced versions.


>  b) ivory-tower

The only reason for having xml:id in the first place is to allow for 
hypothetical cases that on paper look simpler because of specification 
reuse.

xml:id is an orthogonal spec that doesn't need to be mentioned in XBL2.


> > There's nothing wrong with the name "id". The idea that you might need 
> > to manipulate XBL2 documents using Perl on the server side is crazy.
>
> I am always manipulating documents with Perl (or otherwise), on the server or
> simply offline.

Sure. XBL files, however, aren't the kind of documents that you would 
parse on the server-side -- or if they are, that indicates some serious 
problems with XBL. Could you give some examples of how you might interact 
with XBL files on the server side?

Do you interact with JS and CSS files on the server side too?


> Using xml:id instead of id brings benefits to at least some of the folks 
> who intend to use this, and comes at no cost that has been described so 
> far. So what's not to like?

It comes at significant cost, and I have yet to see anyone describe any 
real benefits.


> > Even if you did, XBL2, HTML, SVG, and other such languages, which are 
> > all intended to be "core" languages, can trivially be supported 
> > natively by your perl library, and don't need to use "xml:id".
> 
> If it is so trivial I would be indebted to you if you were so kind to 
> provide me with the code that handles querying compound documents of the 
> above as easily and with comparable performance to using xml:id. I'm 
> always happy to learn a new Perl trick.

At the point in the code where you look for an "id" attribute in the XML 
namespace, simply replace the code with looking for an "id" attribute on 
an element in the XBL2 namespace, in the same way as the existing code 
handles HTML, SVG, and MathML.


Proposed compromise: People can use xml:id with XBL2 anyway. There's 
nothing in XBL2 that precludes using xml:id, and there's nothing in xml:id 
that precludes using it with XBL2. However, the XBL2 specification doesn't 
need to mention this at all, and the XBL2 specification can continue 
having its own private attribute "id" just like HTML, SVG, and MathML.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'
Received on Tuesday, 27 June 2006 19:08:22 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:50:04 UTC