Cart
[Home] [By Thread] [By Date] [Recent Entries]
>> But expressing how to find the IDs in the document at the >> XPointer syntax level won't be fun. If not in XPointer >> then it's either the instance or the DTD. Did I miss something ? > > It's also entirely unecessary *except* for the RawName construct in > XPointer. This is an interesting perspective. I think there's a choice to be made here. I would argue that it's a fundamental principle of XML that DTDs are optional. This means that given any XML document with a DTD you should be able to produce a document without a DTD that is equivalent. "Equivalent" means that the infoset of the two documents is the same in all "important" respects. This raises the question of whether the ID-ness of an attribute is "important" or not. We have a choice here. (A) We can choose to say that ID-ness is not important. It's a legacy feature like unparsed entities and notations, and so the fact that it requires a DTD is not a problem with XML. XSLT doesn't have a problem with this perspective because the use of IDs is separated out into the id() function, which does nothing else. I think that Gavin is right that on this view the only problem is the RawName construct in XPointer. So how can we fix XPointer? (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. XPointer got sent back to WD because the XPath in the fragment identifier depended on namespace declarations in the referencing document. It would be horribly messy to try and fit a declaration of what attributes were ID attributes in each an every fragment identifier. It would also completely lose the point of the RawName construct: that it is simple and has the same form as fragment identifiers in HTML and other content types. (ii) I understand Gavin to be suggesting that we simply get rid of the RawName construct. 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'm not sure. (iii) Another potential solution is to break connection between XPointer RawNamess and XML IDs. For example, XPointer could define a global attribute xptr:name and could declare that #foo construct refers to the element with xptr:name="foo" (or maybe an xptr:idatt). (B) The other choice we can make is to say that ID-ness is important. On this view the problem lies not with XPointer but with XML. Using the interal subset is not an adequate solution. This is not a case of vendors needing to get their act together. There are basic reasons why the internal does not work: (i) Some profiles notably SOAP don't allow it: it's not reasonable to do DTD processing for every RPC call (ii) It doesn't work properly with namespaces: it makes the prefix used by an element or attribute name significant (iii) It doesn't work with streaming output. This is in my view the most important technical problem. xml:id isn't a solution at all: it doesn't allow you to produce an DTDless document that is equivalent with respect to the ID-ness of attributes. The only solution that I've seen that works with choice (B) is xml:idatt(s). 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 James
|
