[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: 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 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.
|
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|