RE: Options for dealing with IDs

Tim Bray:

>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>

Thinking out loud: A perhaps simpler way is to say that an XML 1.x processor
itself does nothing special to xml:id attributes, and that a document author
SHOULD include some kind of DTD/schema definition that formally declares the
attribute xml:id to be of type ID.

A later (or earlier??) stage of processing can make sure that the infoset
gets arranged with the needed [attribute type] information. RELAX NG gets
the separation of ID from validation right, IMHO.

What would the advantage be? In cases where the DTD/schema (by choice or
not) isn't read, the overall behavior will still be the same.

>I have never prior to this discussion seen a sustained burst of the
>energy from the community demanding change in this area.

Even though my personal experience doesn't agree, this is a reasonable
observation. I believe the one reason for this is that only now are
multi-namespace documents (especially ad-hoc ones not predefined with a
DTD/schema) becoming mainstream.

More in a separate message.

.micah

-----Original Message-----
From: Tim Bray [mailto:tbray@textuality.com]
Sent: Saturday, January 11, 2003 2:00 PM
To: Chris Lilley
Cc: www-tag@w3.org; Norman Walsh
Subject: 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).

<snip/>

Received on Monday, 13 January 2003 13:40:50 UTC