• To: James Clark <jjc@j...>, xml-dev@l...
• Subject: Re: So maybe ID isn't a problem after all.
• From: David Brownell <david-b@p...>
• Date: Mon, 12 Nov 2001 22:51:51 -0800
• References: <E163Qf2-0008CL-00@s...><360680761.1005641126@[192.168.0.152]>

> To summarize, I think the reasonable choices are:
> 
> (a) Remove the RawName construct in XPointer
> (b) Change the semantics of the RawName construct in XPointer to say that 
> it refers to, say, a element with a xptr:name attribute with a particular 
> value
> (c) Add an xml:idatt(s) to XML

Seems like (b) is isomorphic to the xml:id construct, so if you
believe xml:id doesn't work, then for the very same reasons
it'll be true that xptr:name doesn't work.  Both have the same
problem transitioning old apps to new attributes.  Not unlike
moving to "id=..." in current HTML; solvable.

On the other hand, I'm not sure I bought that claim, or the
problem definition requiring DTD stripping not to discard any
"important" information.

I clearly don't want to see (a) happen, and (c) does seem to be
avoidable complexity (so many in-line declarations).

- Dave

• References:
  • Re: So maybe ID isn't a problem after all.
    • From: Gavin Thomas Nicol <gtn@r...>
  • Re: So maybe ID isn't a problem after all.
    • From: James Clark <jjc@j...>

• Prev by Date: Re: SAX Parsing of an XML file
• Next by Date: Re: So maybe ID isn't a problem after all.
• Previous by thread: Re: So maybe ID isn't a problem after all.
• Next by thread: Re: So maybe ID isn't a problem after all.
• Index(es):
  • Date
  • Thread