[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [xml-dev] So maybe ID isn't a problem after all.
On Monday 12 November 2001 08:45 pm, James Clark wrote:
> (i) Tim observes that the author will usually know what things are IDs. I
> agree, but I don't think this solves the problem. There are only two
> places where the ID-ness of an attribute can be specified: in the
> referenced document or in the fragment identifier. It is not workable for
> the ID-ness of an attribute to be specified by markup in the referencing
> document outside the fragment identifier.
Tim's point, I believe, is that from an authoring intent perspective, the
ID-ness is irrelevant because the author knows what he's doing.
> (ii) I understand Gavin to be suggesting that we simply get rid of the
> RawName construct.
Better that than kludges...
> This runs into the well-known inconsistency in the Web
> architecture: the meaning of a fragment identifier is supposed to be
> determined by the media-type, yet a single URI reference may return
> different media types because of HTTP content negotiation. Would it matter
> that you couldn't have a fragment identifier in XML that was a simple name?
I think HTTP negotiation only really works for media of roughly the same
types, or requests for complete objects. For example, I get GIF's instead of
I'd be most annoyed if I asked for
and was expecting it to conform to the docbook DTD, and got back a PDF
file.... or worse, an SVG document, or a big TIFF image. In the face of
content negotiation, a lot of code in the world is very much broken....
Then again, this is still something of a red herring. If I asked for
and the system wanted to return generated PDF instead, it has the
responsibility of preserving the semantics of the fragment id. If I were a
site administrator, I'd probably have this redirect to
Anyway, the flaw in HTTP is pervasive, and if we *really* care, this issue
might be better fixed there.
> (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
> (c) Add an xml:idatt(s) to XML
These are all reasonable choices, I agree.