Re: Comments on XPointer last call

At 11:39 PM -0500 12/27/99, David Beech wrote:
>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

(A) It's known to be possible. Although the mapping may be difficult, real
prior systems have done this. Thus it is known, not a mere premise, that it
is *possible*. There is also published literature on it, and a number of
workable methods, the most obvious inserting "trace" data during
transformation. This is a matter dealt with in formal language and automata
theory, in linguistics, and in other domains as well. But even if it were
impossible, it would not follow that ranges would be meaningless; nor would
application requirements for them cease to exist.

(B) The mapping difficulty has nothing specific to do with ranges, or even
with XPointer. An XSLT transform (or Perl or...) can easily make all IDs
and NAMEs go away, making even plain old IDs or HTML fragment identifiers
not work. Therefore to address this comment consistently W3C would have to
discard not only ranges, but XPointer, XPath, and fragment identifiers in
their entireties (of course, one could instead discard all transformation
mechanisms). I for one do not support such tactics. Only XSLT can define
the semantics of XSLT transforms.

(C) Ranges are defined just fine whether or not a mapping is possible. They
are also useful. Perhaps you have an implicit implementation and use model
in mind, where, for example, one cannot assign a separate URL to each
transformed version of a document, cannot carry trace information or
maintain two trees simultaneously in relation, etc.... But under those same
assumptions much more than just locators (of whatever kind) breaks. Note
for example my earlier mail regarding some far  more troublesome common
cases: Multiple transforms, time- and environment-dependent transforms,
confidential transforms, etc. The problem is inherent to transformation,
not to pointing.

>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

This seems untenable. Since DOM defines ranges (we use the same
definition), and does so without referring to presentation at all, they
must be meaningful for more than presentation (or I guess we should
withdraw DOM too?). The ranges that exist for a given document are
precisely defined and meaningful regardless of whether presentation is
involved. I do not see how your comments about 16-bit characters are
relevant unless you are claiming that "16-bit characters" only exist once a
presentation is in play, which is clearly not the case.

>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.

You may note that other use cases have already been cited on the list.
Also, the *primary* application, for which XPointer was chartered, cannot
be solved without ranges. So regardless of how many applications need only
a subset, the point remains that there exist requirements for the full
capability. It would seem a bit odd to me, to release a recommendation from
the XML Linking working group, that was intended to enhance hyperlinking
functionality on the Web, that worked only for NON-hyperlinking
applications....

Your argument appears to be that since there exist applications that do may
not need ranges, therefore XPointer need not fulfill the requirements of
applications that do (even when the main application that DOES, is the one
for which XPointer is chartered). That seems untenable.

In short, losing ranges won't help, since the same problems you cite arise
with many others constructs already; but it would cause XPointer to fail to
fulfill its primary purpose, even though it might fulfill some secondary
purposes.

s

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

Received on Tuesday, 4 January 2000 11:34:25 UTC