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

XPOINTER comments

From: Jim Trezzo <jtrezzo@us.oracle.com>
Date: Tue, 28 Dec 1999 21:36:00 -0800
Message-ID: <38699DC0.DA1BA268@us.oracle.com>
To: www-xml-linking-comments@w3.org
CC: jtrezzo@us.oracle.com, mscardin@us.oracle.com, dbeech@us.oracle.com
Below are Oracle's comments on the XPOINTER last call.  Please excuse
the late response, I have had some e-mail outages to deal with.

Jim Trezzo

The XPointer support for Ranges as detailed in the current working draft
the following implementation and usage problems when considered across
various XML technologies, specifically XSLT.

1.  The premise that a selection of a series of characters or strings on
output tree can be referenced back to the source tree for the generation
an Xpointer Range is flawed if the output tree has had any but the
of transformations applied to it via XSLT.  In fact, since the
can add new elements itself, there may not even be an input tree element
reference to.  After discussing this functionality with our development
group, the conclusion is that there is no way to implement XPointer
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
into the picture the internalization issues of what defines a selection
the resulting characters.  The DOM working group, when faced with a
problem, elected to define "character" as a 16-bit unit.  We see no such

definition here, and therefore see this problem unresolved even if
were confined to the output tree.

3. XPointer support is a requirement across many of the XML
and thus implementations are looking to ease the complexity and amount
code necessary to be compliant without limiting core functionality.  The

inclusion of ranges adds significant code without a clear requirement
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
optional feature considered for version 2 if at all.
Received on Wednesday, 29 December 1999 00:36:32 UTC

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