Re: fragment exchange (was Re: rationales for TEI extended-pointer keywords)

At 01:54 PM 06/13/97 +1000, Rick Jelliffe wrote:

>They asked about how what gets returned by a ID(x1)..ID(x2) when these ids
of  element in 
>different branches of the element tree: does just the text get returned or
does a clipped tree 
>get returned or what. If text is returned, is it XML.. I didn't know.  Any
ideas yet?

Thinking of it as returning some actual data inevitably leads to problems.
Whether it "returns" something, and just what, is hard to say. Remember that
a reference to data is not the same as the data itself. And spans only
really make much sense as a *reference*.  This is much like the distinction
missed by an infamous query language long ago, which required that if you
searched for a word, say "foo", what you would get back was every "foo" in
the searched document(s):

foo
foo
foo

This is just a tad less useful than returning

ID (sec2.1) CHILD (5 P) TOKEN (5)
ID (sec3.7) CHILD (99 I) TOKEN (27)
ID (sec3.7) CHILD (99 I) TOKEN (39)

It is possible to get a list of three copies of the string "foo" from a list
of three pointers to them; the reverse is not possible (if it is, you're
carrying around some *other* information secretly to do it, and *that*
information is what we're really talking about then).


>traversing a link with pointer ID(x1)..ID(x2) to would get a document like
this:

Exactly the point: you *don't* get "a document" at all. You get a reference
to a range of data in a document. Not the same thing.

Whether the string that existed in the pre-parsed XML document is a useful
thing to retrieve and process apart from its context is
application-dependent. An editor might want to support pasting it in in
place of an identically-asynchronous span in some other document, for
example; but a viewer could not likely make much sense of it (even if it
recovered gracefully from WF violations).

A span is not a subtree; that's why it's a span.



>No. Mine didn't: they were commmercial HTML & SGML suppliers, from legal &
CALS areas mainly, 
>and they were more interested in users being able to access information
only by the elements
>the providers had marked up. They generally don't want users to play with
the data.

In that environment, it may well be that you don't need spans; or even that
you specifically need to rule out use of spans. Or you might want to insist
that spans are never tranferred out of context. Indeed, many applications
will always want to send subtrees of a given level (say, SECTION), and then
simply highlight a target within it. Perfectly normal hypertext system
behavior, and "selection" and "document" need not by interchagneable concepts.


Steven J. DeRose, Ph.D., Chief Scientist
Inso Electronic Publishing Solutions
   (formerly EBT)

Received on Friday, 13 June 1997 13:35:22 UTC