Re: Last Call review of XML Pointer WD Version 1.0

Paul Grosso wrote:
> 2.  As long as XPointer can address any point in an XML document,
>     you can give two XPointers and allow the application to figure
>     out how to interpret them as specifying a range.

I cannot find any new arguments in your posting, although the WG has
repeatedly decided against your position on this.

You still have not, as far as I can see, ever addressed the scenario where
the average user drag-selects something and says 'make link' or 'make
annotation' -- most things one can drag *are* ranges: not anything you can
point at with XPath.

Support for this user action is specifically called out in our
requirements. More important, it will literally be a million-time-an-hour
event on the Web -- the sine qua non of annotation -- are we to leave it
crippled?

I am honestly amazed that you are suggesting 'two xpointers makes a range'
yet again, Paul. This would have several nasty effects that have been
discussed and acknowledged in the WG; so far as I'm aware you have not yet
addressed any of the problems that have previously been raised with your
proposal, nor shown a worked-out example (I have shown an example in my
replies, and I think it makes the unworkability pretty clear, as it did to
the WG).

Since the entire list you mailed may not have seen the original
discussions, I re-post below my original reply (Wed, 10 Feb 1999 10:39:36
-0400) from when the same scheme was suggested by Eve, who was at that time
serving as your alternate (my reply was also reposted later when you
re-raised the question). After my reply on the original occasion, Eve said:

>Date: Wed, 10 Feb 1999 18:19:14 -0500
>To: w3c-xml-linking-ig@w3.org
>From: "Eve L. Maler" <elm@arbortext.com>
>Subject: Re: Keeping linking simple
...

>I really like your analysis of why spanned regions need to be represented
>in single XPointers; you've convinced me.  I don't think I'd seen any of
>these points made before.
>
>	Eve


Anyone interested can find more in the archives. The short form is that if
you don't have ranges IN XPointer, then clearly you can't link or annotate
everyday user selections unless you have XPointer AND some other spec --
you have often suggested XLink as the 'other' spec. But since XPointer, not
XLink, is what can be put in a fragment identifier, your proposal means
that URI References cannot be used for creating annotations except to whole
elements. QED.

If instead you put two XPaths together inside an XPointer (instead of an
XLink), then you have just the range construct we have specified in
XPointer already.

Paul, if for your application you want some construct that can *only* point
to whole elements, that's great: just use XPath. But don't cripple every
end user's ability to do the simplest annotation, by imposing a huge
limitation on everyone. Remember that we are, with XPointer, defining what
can be done with fragment identifiers for all URIs pointing to XML
documents.



---------- The original reply ----------

>What if your link did the job of encoding the span, instead of your
>pointer, by having two locators with the respective semantics of "start of
>selection" and "end of selection"?

We can't shift addressing glibly from XPointer into XLink. Doing it would
implement a basic misunderstanding of the distinction between pointing or
addressing on the one hand, and linking on the other. I know HTML <A> does
that, but it's one of the most important things we're trying to get past.
And while perhaps such a misunderstanding is not in itself deadly, its
consequences are.

Here are a few of the practical consequences that would follow:

Let's say you try to do precisely the move you and Paul have suggested. So
now you've got a link somewhere like:

<link>
  <locator role=start-of-scope href="id(foo).child(3).string('foo')">
  <locator role=end-of-scope href="id(foo).child(3).string('foo')">
</link>

What's wrong with that? Here are a few of the problems:

A) the roles are at best bogus -- these two locators clearly do not have
link-end roles (much less titles!), and we have to fudge something for them
or complicate XLink by reserving special semantics for this case.

B) Typical semantics for linking, like "provide traversal from one end to
the other", are inappropriate. So we'd better add some more reserved words
to the XLink sytnax to label these.

C) It's pure coincidence that the two hrefs look similar.

D) There's no way to ensure that the ends even occur in the same document,
much less in the right order. With span() inside a single XPointer, much of
that relationship is expressed automatically and naturally:
id(foo).span(child(1),child(4)).

E) Note that this link isn't the one you care about anyway: you now have to
create another link up top, that points to this link as its linkend. So now
links have to be recursive, which they weren't before. We didn't need that
before, I believe.

F) You can't really embed this kind of thing in a URL.

G) A system that just supports XPointer can't represent most user
selections at all: you have to have XLink and XPointer.

H) Even when you've got both XPointer and XLink, something very weird and
complicated happens in your implementation: If the user happens to select a
whole element, they get an XPointer; but if they select a single word,
point, or character, or anthing else, then they can't get an XPointer at
all, any any XPointer processing that may be supported just went away:
instead they get an XLink, and any links they now make becomes recursive
links. Oy.

I) Fundamentally, this is using XLink to represent a *location*, not a
link; and that is by definition XPointer's job.

J) A corollary of (I), is that since XPointer "owns" the part of the URL
after the "#" for XML, XLink can't even get in there; so you can't do it in
the first place. Or are we planning to combine the two spes and allow any
full-fledged XLink to be escaped like crazy and embedded in the fragment
identifier? And if that, what in the world would it mean? Or can you only
embed the one special case of XLink, that is truly a pointer anyway? And
how do we say any of that in the spec?


I hereby reclaim the high moral ground of simplicity.

I propose that any future suggestions to push addressing functionality up
from XPointer to XLink show worked-out examples. Maybe the scenario above
isn't obvious to all, but something very much like that is inevitable if we
go the route of shifting the work to a spec that's aimed at a different
purpose, and out of the one that's aimed at the relevant purpose.


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

Received on Thursday, 16 December 1999 00:23:14 UTC