W3C home > Mailing lists > Public > www-xml-linking-comments@w3.org > October to December 1999

Comments on XPointer last call

From: David Beech <dbeech@us.oracle.com>
Date: Mon, 27 Dec 1999 20:39:56 -0800
Message-ID: <38683F1C.88841609@us.oracle.com>
To: www-xml-linking-comments@w3.org
On behalf of our AC rep Jim Trezzo (who is on vacation),
I am submitting the following Oracle comments on ranges
in XPointer.

Thanks,

  David

============================================================
1.  The premise that a selection of a series of characters
or strings on an output tree can be referenced back to the
source tree for the generation of an Xpointer Range is
flawed if the output tree has had any but the simplest of
transformations applied to it via XSLT.  In fact, since the
stylesheet can add new elements itself, there may not even
be an input tree element to reference to.  After discussing
this functionality with our development group, the conclusion
is that there is no way to implement XPointer Ranges where
the reference is to anything but the output tree itself.
Non-range forms of XPointer have many uses independent of
output trees, but the range form seems to be special in that
its most obvious use case is dependent on the viability of
inverse transformation from output to input tree.

2. The concept of range, especially in the use case being
offered, inherently is linked to the presentation of the
output tree.  This brings into the picture the
internalization issues of what defines a selection and
the resulting characters.  The DOM working group, when
faced with a similar problem, elected to define "character"
as a 16-bit unit.  We see no such definition here, and
therefore see this problem unresolved even if ranges
were confined to the output tree.

3. XPointer support is a requirement across many of the XML
specifications and thus implementations are looking to ease
the complexity and amount of code necessary to be compliant
without limiting core functionality.  The inclusion of ranges
adds significant code without a clear requirement beyond the
use case which exists only in presentations.  XPointer support
is required even when there is never going to be human readable
output.  We would recommend that such narrowly scoped
functionality as ranges be in an optional feature considered
for version 2 if at all.

=================================================================
Received on Monday, 27 December 1999 23:42:53 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:32:21 UTC