W3C home > Mailing lists > Public > www-tag@w3.org > January 2003

Re: Options for dealing with IDs

From: Robin Berjon <robin.berjon@expway.fr>
Date: Wed, 08 Jan 2003 11:06:08 +0100
Message-ID: <3E1BF810.1040804@expway.fr>
To: Chris Lilley <chris@w3.org>
CC: www-tag@w3.org

Chris Lilley wrote:
>   4) Add a predeclared id attribute to the xml namespace

This is by far my favourite option, it's simple and efficient. I've been using 
something similar (an id:id attribute) to ease processing of multi-namespace 
documents and have been happy with it.

>   Advantages
>   - no clash with DTDs or Schemas

What happens when a DTD declares attribute "name" to be of type ID and it occurs 
on the same element as xml:id with a different id, in a validated document? I'll 
grant you that's stupid behaviour, but one that needs to have a defined 
behaviour (this applies to other options as well). I'd be in favour of having 
the declared attribute take precedence there as it'll be more backwards compatible.

>   Disadvantages
>   - requires a (small) change to XML spec and XML parsers

Not really, xml:base didn't affect either directly.

>   5) Add an inline, per-instance ID declaration method
>   6) Add an inline, per subtree ID declaration method

I could live with these two but I think they open cans of worms here and there.

For option 5, what happens when I XInclude a document that has xml:idAttr on its 
root element? Do I get to rewrite the new subtree so that all occurences of the 
id attribute match the xml:idAttr of the including document?

Option 6 doesn't suffer from that problem but it does have the drawback that you 
need to keep a stack of id attribute names. IDs are meant to be simple, I'd 
rather one shouldn't need to carry an IDSupport class along with the usual 

I also generally dislike the fact that they're not really namespace aware. If 
I'm planning to have a complex document with many potential (and potentially 
evolving) namespaces, I'll want to pick a safe value for xml:idAttr to be 
certain that it doesn't mean anything in any of the possible vocabularies. Using 
a QName would be an option, but I'd rather keep away from QNames-in-content. A 
PI of course could work, but I suspect I'll be the only one to think that ;) 
(and it would have issues unless it's constrained to appear before the root 

Robin Berjon <robin.berjon@expway.fr>
Research Engineer, Expway        http://expway.fr/
7FC0 6F5F D864 EFB8 08CE  8E74 58E6 D5DB 4889 2488
Received on Wednesday, 8 January 2003 05:07:12 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:55:56 UTC