Re: Last Call review of XML Pointer WD Version 1.0

At 16:09 1999 12 05 -0500, Daniel Veillard wrote:
>"XML Pointer Language 1.0" Last Call Working Draft. 
>The document address is:
>
>       http://www.w3.org/TR/1999/WD-xptr-19991206

>moving to last call, the Working Group asserts that it
>has met the requirement of its charter [4] "XPointer, is intended to
>specify the fragment identifier syntax when pointing into resources
>with XML media types (text/xml, application/xml).

As a member of the XLink WG, I appreciate all the work that has
gone into this draft.  However, I think that the current draft
reaches a little too far.

As quoted above, the charter for XPointer is to be the fragment 
identifier syntax for XML resources.  It is not supposed to be
a query language, it is not supposed to "return" anything, it
should be optimized to address into XML structures.  Anything
that makes it look more like a query language than an addressing
mechanism (and I realize that this forms a continuum with no
strict dividing line) concerns me.

Specifically, I have consistently been opposed to adding the 
range type to XPointer.  A range is not one of the "native" 
structures in an XML parse tree.  In fact, as defined by the 
current XPointer draft, a range needn't be well-formed XML. 

I realize that the use case for ranges is supposed to be to model
user selections.  However:

1.  Ranges greatly complicate the language that has to be implemented
    by *every* application that accesses XML resources (since XPointer
    is the fragment identifier syntax for the XML media type).

2.  As long as XPointer can address any point in an XML document,
    you can give two XPointers and allow the application to figure
    out how to interpret them as specifying a range.

3.  "User selection" assumes interaction with a presentation view, and
    yet XPointer operates on the XML source tree; since there cannot be
    a mapping from the displayed view back to the source tree in the
    general case (e.g., consider a complex XSLT transformation generating
    the displayed view), the idea that a user selection in the displayed
    view provides a use case for ranges in the source needs more thought.
    (The Note at the end of section 3.1 that mentions this issue doesn't
    strike me as sufficient discussion of this difficult issue.)

I am also concerned for similar reasons to 1 and 2 above that a single
XPointer appears to allow the addressing of multiple nodes.  In section 2.4,
the spec says that, since "XPointers are not a general query mechanism...an 
empty result is a sub-resource error."  If XPointer is not a general query 
mechanism but is rather a fragment identifier syntax, then it seems equally
erroneous for a result to return multiple nodes, especially disjoint ones.

Yet "XPointer also defines location-set as a generalization of XPath's 
node-set", so it appears that XPointer can refer to sets of potentially
disjoint nodes.  In section 3.7, a "unique" function is defined which is
"particularly useful in applications where a single location is to be 
located for automated processing and an XPointer that does not locate 
exactly one location would be in error."  

I would have preferred to see an XPointer spec that subsetted XPath
so that XPointer was much simpler and restricted to addressing single
nodes in the source document.  Given where the XPointer spec is now,
at the very least I think there needs to be a lot more discussion
about what it means for XPointer to address multiple, possibly disjoint,
node sets when XPointer is used as a fragment identifier in a URI, and
I would very much like to see range removed from XPointer.

paul

Received on Monday, 13 December 1999 12:33:01 UTC