- From: Steven J. DeRose <sjd@eps.inso.com>
- Date: Fri, 13 Jun 1997 13:31:33 -0400
- To: <ricko@allette.com.au>, <w3c-sgml-wg@w3.org>
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