Re: [xml-dev] IDs considered harmful or why keys might be better than IDs...

["Jonathan Borden" <jborden@mediaone.net>]

Eric,

>
> Yes, and I have been provocative on purpose... This is, nevertheless,
> not completely pointless and the fact to provide a "hardwired" IDs will
> push many people who would otherwise have needed to be more creative
> into using these IDs.
>
>

Of course it is implicit that you are being provocative on purpose :-))

Likewise we can make the point that there is a distinction between an XML
_structure_, e.g. element, attribute, fragment and what a particular
application considers an _object_. Certain applications such as HTML
browsers may have standardized objects (e.g. DOM) and other applications may
use XML to serialize their own objects, but we need to distinguish between
this XML and the application object. Perhaps this is the point you are
making and if so I agree.

> >
> > Fragment identifiers of URIs are intended to be parsed according to
media
> > type (perhaps application/xml) and as such the idea that there is an
"XML
> > name" for a fragment of a document is a completely valid one, of course
> > realizing that other applications may choose to name things in different
> > ways. For example XSLT keys or XML Schema keys, the point being that if
the
> > HTTP server returns the document of media type application/xml, that the
> > fragment identifier will have a consistent interpretation. It is
important
> > to start with this as a basis.
>
>
> But, the basis that will be chosen will be more or less extensible.
>
> Using "xml:id" is probably the less extensible basis (even less
> extensible than DTD's IDs were).
>
> {http://purl.org/xmlid}:id is hardly more extensible and the first
> solution which IMO gives it some flexibility is James Clark's xml:idatt.

Of course but we _already have_ a more extensible mechanism for defining ids
and keys, namely the DTD and XML Schema. As I've said, one can do all this
in XML 1.0 using an internal subset, so I am not sure that we really need a
_more_ robust solution -- then we will simply have yet another robust soluti
on.

The only reason that I see the need for something really lightweight like
"xml:id" is that internal subsets are not well handled by common software
(e.g. SAX), but I don't think that is the fault of XML 1.0, rather by the
assumption that not everything is important, i.e. a _Simple_ API for XML is
fine and good until you need to do something slightly complex.

>
> The keys which I was thinking of could follow the syntax defined by XSLT
> and be defined either:
>
> 1) In the document:
>
> <foo><xxx:key
>    name = qname
>    match = pattern
>    use = expression />
> </foo>
>
> 2) Linked from the document:
>
> <foo><xxx:key-ref
>    xlink:href="mykey.xml"
>    xlink:type="simple"/>
> </foo>
>
> 3) Defined in the URL
>
> In the first 2 cases, this would be the usual http://foo.xml#bar, but
>
> http://foo.xml#key(http://mykey.xml,bar)
>
> with the same tricks than XPointer is using to declare namespaces URIs
> could be used to point on another key.
>

Certainly, but why stop here! Why not go all out and allow inline XML Schema
syntax. Similarly XPointer defines 3 forms, including raw names which
presumably point to xml:id like attributes. The full xpointer syntax
includes XPath so complex "keys" can indeed be already built from the
current proposal.

What I wish to avoid is having 5 different ways to do _everything_ because
that needlessly complicates XML.

Jonathan