On Jun 27, 2006, at 19:33, Ian Hickson wrote:
On Tue, 27 Jun 2006, Robin Berjon wrote:
The xml:id is not meant for "proprietary" languages, it's meant so
that
you can usefully manipulate a document without having to first
implement
a specialised DOM. When you want to do simple server-side (or
otherwise
offline) Perl hacking, it's a killer feature. Unlike XLink it has no
declaration overhead (and is actually useful). It comes for free and
works — what more can one ask for?
This is exactly the kind of impractical ivory-tower arguments that
caused
XBL2 to leave the W3C last time.
Would you mind taking the time to explain what about the above
position is:
a) impractical
b) ivory-tower
c) conducive to XBL leaving the W3C
?
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. No offence intended but if you look at it
with a cool head you might agree that calling other people's uses
"crazy" just because you don't have the same yourself would seem to
me to be more ivory-tower than the reverse.
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?
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.
--
Robin Berjon
Senior Research Scientist
Expway, http://expway.com/
