Re: XPointer ranges cost effective?

At 6:02 PM -0000 12/27/99, Jonathan Marsh wrote:
>I'd like to enter a plea for removing ranges from XPointer on the grounds of
>cost effectiveness.  Two of the initial applications most important for us
>are the XSLT document() function which accepts an XPointer, and XInclude
>(draft stage).  Due to the complexity of figuring out how XPointers
>returning ranges are to be interpreted, both of these technologies decline
>to process ranges, resulting in an implementation burden with no
>corresponding functional benefits.
>
>It seems that there will be a tendency for XPointer implementations to fall
>into two classes, those that require ranges, and those that prohibit ranges
>such as the two above.  It seems reasonable to defer ranges to a future
>version of XPointer in the interests of gaining greater interoperability, a
>wider base of consistent implementations, and encouraging full compliance
>from all XPointer implementations.

If we delete ranges, we cannot support our most basic requirement:
identifying typical user selections in order to support hyperlinking,
annotation, and the other hypertext activities for which we were chartered.

The fact that there exist other groups/applicationsw that want to use
XPointers but only happen to need some of the functionality, is great, but
does not somehow remove our central requirements to support hyperlinking.

Also, it seems absurd to throw away essentially finished work, with which
no significant technical errors have been raised. A proposal to allow a
subset does not seem absurd, though the most sensible subset I see would be
XPath itself. However, I would strongly oppose allowing such a subset
unless the recommendation makes it very clear that this is not permitted
for applications such as hyperlinking -- else it will be tempting for
implementors to put it off, and as you know, at the last xml linking F2F
people cited multiple actual cases where they had shipped software that
only supported linking/annotation of whole elements, and were very clear
that users strongly hate it -- it's like dragging your mouse in an editor
and ending up with a selection other than what you dragged -- drives people
nuts.

sS

Steven_DeRose@Brown.edu; http://www.stg.brown.edu/~sjd
Chief Scientist, Scholarly Technology Group, and
   Adjunct Associate Professor, Brown University

Received on Thursday, 30 December 1999 13:26:50 UTC