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

[James Clark <jjc@jclark.com>]

>> 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