[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [xml-dev] So maybe ID isn't a problem after all.
>> 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
This is an interesting perspective. I think there's a choice to be made
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
(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
(c) Add an xml:idatt(s) to XML