Re: Last Call review of XML Pointer WD Version 1.0

Paul Grosso wrote:
> 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.

Right. Although that range could still be represented in well-formed XML
as an XML Fragment, right?

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

True.

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

True, although that means that they can't be used as URI fragment
identifiers anymore because you can't readilly have two fragments on the
one URI.

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

This issue is not specific to range - it applies to all fragment
identifiers of any sort, since the element structure that is being
pointed to is the source XML and there is currently no way to know what
that result structure might be, no way to point into the result of an
XSL-T transformation, nor to get a DOM for it, not to do anything much
until it is serialised out and given a (different) URI of its own. So
whilst the points you raise are valid ones, they are orthogonal to the
issue of range.

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

I admit that I find this a compelling argument. Regardless of the
general utility of an XML query mechanism, and regardles sof the
likelihood that it will be based upon XPath (presumably, as subsetted
and enhanced for its purpose); that's a different spec, and a different
WG.

--
Chris

Received on Monday, 13 December 1999 20:05:44 UTC