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
has
the following implementation and usage problems when considered across
the
various XML technologies, specifically XSLT.

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 Wednesday, 29 December 1999 00:36:32 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 27 October 2009 08:39:40 GMT