Re: [xml-dev] So maybe ID isn't a problem after all.

[Gavin Thomas Nicol <gtn@rbii.com>]

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 
JPG's. 

I'd be most annoyed if I asked for

  http://www.foo.com/foo.xml#foo

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

  http://www.foo.com/foo.xml #xpointer(//*[@id='foo]) 

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

  http://www.foo.com/foo.pdf#foo

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
> value
> (c) Add an xml:idatt(s) to XML

These are all reasonable choices, I agree.