Re: Options for dealing with IDs

Chris Lilley wrote:

> This is the current mess. This is 7) Muddle along. This is "lets
> insert some user agent sniffing on the server so that we can get a bit
> more interoperability". And this is, to be harsh but fair, the utter
> shambles that Tim Bray proposes we get comfy living in.

C'mon Chris, stop holding back, tell us what you *really* think.  OK, I 
admit to already being comfy with the way things are; furthermore, I 
have never prior to this discussion seen a sustained burst of the energy 
from the community demanding change in this area.  I think everyone is 
probably prepared to be convinced that we have a problem here if enough 
people pipe up about it.

So.... let's think about this in a little greater detail.  Suppose we 
were to adopt the "xml:id" solution - I examine that one because it's 
probably the simplest, involving the fewest corner cases.  I'm not 
trying to prove anything, just thinking through this in public.

XML 1.* says that when a DTD declares that an attribute is of type ID, 
then it is a validity error if

(a) it is syntactically anything but a NAME, and
(b) there are two attributes so declared in the same document with the 
same value
(c) there are two attributes so declared which can be attached to the 
same element (not an issue with xml:id, but with xml:idAttr)

(BTW, I'd think it would be advantageous if we could junk conditions (a) 
and (c) as a side-effect of our work here).

What are the other defined semantics of ID?, XPointer drafts suggest 
that an xpointer consisting only of a NAME means "the element which 
contains an ID attribute whose value is that NAME".

Then there's the DOM call, but I suspect that the definitions there are 
sufficiently fuzzy so as to make the impact of changes low.  Are there 
any others out there?

So one way we could write this is to say that an XML processor should, 
when it encounters xml:id= on element any:thing, pretend that it saw a 
DTD declaration along the lines of

<!ATTLIST any:thing id ID #IMPLIED>

which would require a validity error if either (a)-(c) above do not hold.

So this would require some basic redefinition work on XML 1.*; let's 
optimistically assume XPointer would get the semantics by reference, and 
the DOM would sort things out.

It also ties the semantics of xml:id very close to the ID notion from 
DTDs as expressed in (a)-(c) above.

Seems off the top of my head that it might be smarter to invent a new 
thing with a new name, call it an "address attribute" or AA for short. 
An AA would have the semantics that

(aa1) it can be applied to any element
(aa2) to function most effectively, the value of an AA SHOULD be unique 
in the containing document.

I don't see any need to drag validation or NAME-syntax issues in.

In fact, for the purposes of XPath and XPointer and the DOM, you don't 
*really* need to require uniqueness, you just say that foo#bar matches 
the first instance of an AA with value "bar" in the document.  Worked 
just fine for NAME= in legacy HTML for years.

And on reflection, it seems like xml:id would be kind of ineffectual, 
since it wouldn't help all the languages already out there who would (if 
Chris is right) like a standardized way to tell a processor that id is 
an ID.  So you probably have to go all the way to xml:addAttrs=... or 
maybe xml:AAattrs; oh joy, another declaration mechanism.  More Qname 
cruft.  Bah.  -Tim

Received on Saturday, 11 January 2003 17:00:55 UTC