[xml-dev] Re: determining ID-ness in XML

[Tim Bray <tbray@textuality.com>]

[Trying to keep this one on both xml-dev & ietf-xml-mime]

At 08:40 AM 29/10/01 -0600, Paul Grosso wrote:
>Here are some options (all discussed before):
>1.  use the internal subset to declare IDs

#1 is minimal-impact.  Can it be sold?  I.e., if you
want the "name" attr to be an ID, then you need the following
at the top of the file with a line for each element type
that "name" can appear on:

<!DOCTYPE rootType [
 <!ATTLIST element1 name ID #IMPLIED>
 <!ATTLIST element2 name ID #IMPLIED>
 ... etc...
]>

I'm not sure it's going to be easy to get the community to
buy into this.

>2.  use a PI to declare IDs

Yecch.  Barf.  Blecch.  Feh.  Oh, this is supposed to
be a technical discussion.

>3.  put an xml:id attribute into the xml namespace
>Are there others?  What are the pros and cons?

The advantage of xml:id is that the "xml" namespace 
doesn't need to be declared per the namespace rec.

You could have another namespace declared like so

<rootEl xmlns:xmlid="http://www.w3.org/2001/xmlid/">
 <foo xmlid:a="label1">
 <bar xmlid:b="label2">
</rootEl>

where the semantic is that no two attributes in this
namespace can have the same value in the same doc, 
and you *might* even be able to get away without requiring
a namespace declaration, since those beginning in "xml" are
reserved per the namespace spec, presumably for exactly
this kind of thing.

Note that this is not mutually exclusive with having xml:id.  

My own opinion is that this is unnecessary complexity - just
use xml:id... the advantage of having a new namespace, that
you get to choose your own names for IDs, is kind of 
obviated by the fact that attribute prefixes don't default
so you're always going to have that ugly xmlid: in front, so
why not just bite the bullet and use xml:id?

And as I said, I think it's still not too late to take this
kind of a step.

>In short, what's the right answer?

Procedurally?  A new W3C note leading to a tiny 2-page REC,
I'd say.  Easier than re-opening either the XML or Namespace
RECs. 

The namespace approach(es) have the huge advantage of making
an important semantic aspect of XML documents self-
documenting.  In fact, on the Web, I might argue that the
lack of a clear self-documenting way of establishing the
semantics of '#whatever' in a URI reference is a nearly
fatal architectural flaw.

Hm.... the one problem is that if you're dealing with XHTML
or SVG, which already *have* ID elements defined normatively
as part of the language, you have to say what happens when
there's a conflict, e.g. suppose you have

<html:div id="p3"> ... </div>
<html:div xml:id="p3"> ... </div>

Is this an error, or does the built-in id "win", or do we
leave it up to language designers to define how to coexist
with xml:id?  -Tim