W3C home > Mailing lists > Public > w3c-sgml-wg@w3.org > June 1997

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

From: Steven J. DeRose <sjd@eps.inso.com>
Date: Mon, 16 Jun 1997 13:00:44 -0400
Message-Id: <>
To: <ricko@allette.com.au>, <w3c-sgml-wg@w3.org>
At 01:01 PM 06/14/97 +1000, Rick Jelliffe wrote:

>One more try. Let us have linking element:
>I traverse that link. I understand the server-end constructs (or has) a
grove for that document, and
>selects or marks (or whatever) the appropriate nodes as the resource. 
>I am in a browser. I expect a replacement text.  In what form does the
resource get back to me to 

Ahhh, there's the problem. It is not meaningful to return "replacement text"
for a span; at elast to a processor that's expecting XML. A span is not an
XML document; that's the whole point.

So why would you use them? Well, how about if I want to create a link to a
particular location *within* an XML document. Let's say it's a phrase. In
that case I almost certainly don't want some server to hand me back the
phrase; if this is happening in response to a search for the phrase, asking
for "foo bar" and getting back just the 7 character string "foo bar" isn't
real useful; I can get that result with a lot less work (and without a network).

In such cases, you want to retrieve an appropriate document context (maybe
the whole document, maybe a predictable WF subtree like a SEC, maybe some
dynamically constructed XML object). *That* thing forms the display context;
then the receiving processor may operate on the span *in that context*.
Like, it may scroll it into view and highlight it.

A span is, for most purposes, only meaningful in relation to its context.
Therefore any model that attempts to define what a span means *apart* from
its context is doomed to bizarreness and/or failure.

Steven J. DeRose, Ph.D., Chief Scientist
Inso Electronic Publishing Solutions
   (formerly EBT)
Received on Monday, 16 June 1997 13:04:27 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 20:25:10 UTC