XPointer ranges cost effective?

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.

Received on Monday, 27 December 1999 13:03:39 UTC