- From: Chris Lilley <chris@w3.org>
- Date: Tue, 7 Jan 2003 22:52:44 +0100
- 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 UTC