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

Re: Options for dealing with IDs

From: Chris Lilley <chris@w3.org>
Date: Tue, 7 Jan 2003 22:52:44 +0100
Message-ID: <16074349562.20030107225244@w3.org>
To: www-tag@w3.org, Paul Grosso <pgrosso@arbortext.com>

On Tuesday, January 7, 2003, 10:33:56 PM, Paul wrote:

Hi Paul,

PG> At 19:27 2003 01 07 +0100, Chris Lilley wrote:

>>  As requested by Dave Orchard, a listing of the options for dealing
>>  with IDs.
>>
>>  1) Require DTD validation of all instances.
>>
>>  2) Steal all attributes of name id in the per-element partition
>>  Declare retrospectively that all attributes whose name is 'id' are of
>>  type ID because this is common practice anyway.
>>
>>  3) Steal undeclared attributes of name id
>>
>>  4) Add a predeclared id attribute to the xml namespace
>>
>>  5) Add an inline, per-instance ID declaration method
>>
>>  6) Add an inline, per subtree ID declaration method
>>  

PG> How do any of options 2-6 identify attributes of type IDREF?

They don't. I wasn't asked to do that particular exercise.

PG> And how does any of this make much sense without that?

Well, I didn't imagine that the actual concept of ID was being changed
(although Norm argues that if change is being considered then that
concept should be revisited) so did not imagine that IDREF and IDREFS
would alter.

I agree though that in the case of, say, a "tiny XML" that had no
internal or external subset, then a mechanism of declaring attributes
to be of type IDREF and IDREFS would also be needed.

I admit that I tend to see IDREF as:

a) a broken and limited subset of a URI reference
b) not used much

so was not thinking about it when writing my mail.  Which was remiss
of me.


However, along with my favoured solution for ID of a scoped xml:idAttr
I would propose a scoped xml:idrefAttr and xml:idrefsAttr to solve
that particular problem.




-- 
 Chris                            mailto:chris@w3.org
 Hmm how about xml:anyURIRefAttr he mused
Received on Tuesday, 7 January 2003 16:52:47 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Thursday, 26 April 2012 12:47:15 GMT