OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

IDs considered harmful or why keys might be better than IDs...


I have mixed feelings about this long discussion about XML IDs.

On one hand, the concept of ID seems to be very useful and we obviously 
need unique IDs to avoid ambiguity.

OTH, can an ID for application X be exactly the same than an ID for 
application Y? Can we be sure that their needs will be close enough to 
guarantee that they will refer to the same "object" with the same scope?

In real world, giving unique IDs to concepts which seem as universal as 
a "company" has proven to be quite a challenge. Why would it be 
different if the "company" is enclosed in a XML document?

RDBMs have been able to break through because in a sense, they've thrown 
IDs away... Or should I say, they've allowed (or imposed) to every query 
to specify the "IDs" to use in its where clause.

That's a big constraint for SQL: there is no equivalent to foo.xml#bar 
for SQL and you need to know the name of the column to use as the ID (if 
there is one) and write "select * from foo where myid=bar" but that's 
also a major strength.

To deal with the compexity and with the performance issues, RDBMS have 
invented indexes which are "out of band information" and XSLT has 
already dealt with this issue through keys:


A way to deal with this issue would be to find a way to associate both 
concepts and be able to express that you want foo.xml#bar using a 
specific key definition.

A default key definition could be provided within the document or linked 
from the document, but you could also find a way to specify your own key 
during the query.

My 0,02 Euros,

Rendez-vous  Paris pour le Forum XML.
Eric van der Vlist       http://xmlfr.org            http://dyomedea.com
http://xsltunit.org      http://4xt.org           http://examplotron.org