Re: 3.1 b-h: BEHAVIOR

At 10:18 AM 3/3/97 GMT, Henry S. Thompson wrote:

First off, I'm really glad to see some substantive discussion
of this stuff finally get kicked off.  To be fair, I guess we really
needed the ERB to crystallize some options in order to give people 
something to grapple with.

>Sorry to go on so long, but if we're going to do this at all we need
>to be clear what we're doing.  I think in fact groves provide the only
>sensible way to specify what we mean in an application-neutral way.
>So let's try that, using the name SNODE for the node in the grove of
>class Element which instantiates the linking element we're concerned with:

In fact, this is the core of the difficulty; and the reason why the
terminology in my posting ["the resource where the link traversal started"]
may seem non-intuitive.  It has to be.  In the discussion below, I'm
using the new terminology (resource/locator/linking-element) carefully.
I just spent a long time writing this, and find it hard to be both
precise and readable; yet our final spec must be.

A processor may notice the existence of a resource either because it hits a 
linking element that is in-line & is itself a resource, or because another 
doc in the extended link group (== BOS, go look at the draft spec) has a 
linking element with a locator indicating the resource (a paragraph,
or section, or video subsequence, or whatever) that you've just hit.

In the case where the linking element is the resource, INCLUDE, REPLACE,
and NEW are all easy to understand.  In the case where it is *not*, 
REPLACE and NEW are I think easy to understand; INCLUDE is tricky. 
I now realize that when we said INCLUDE we really meant "replace the
linking element, which happens to be the resource, preserving the
surrounding context", while by REPLACE we meant "replace the whole
context".  Well, I think this still works... if a paragraph is 
functioning as a resource, and SHOW=INCLUDE, I think the paragraph
gets replaced by the result of the traversal; if SHOW=REPLACE, the
whole current processing/display context gets replaced.

Or in the spirit of Henry's note... I'm sorry, but I have to explain
this to the world, and I do not believe that I will be able to require
that they first understand the grove formalism.  (I acknowledge that 
this is an open issue, and some may wish to argue that we *should*
require use/understanding of groves).  But for now, it's gonna have
to be comprehensible standing on its own:

INCLUDE: on actuation, replace the resource where the traversal
started with the resource(s) resulting from the traversal.

REPLACE: on actuation, replace the entire current display/processing
context with the resource(s) resulting from the traversal.

NEW: on actuation, create an entire new display/processing context
with the resource(s) resulting from the traversal.

Note - I am worried that I am forced to keep talking about
"display/processing context" - it feels like there is another
concept struggling to get out here.  I am having a *hard* time
freeing my thought processes from pictures of browser-like
on-screen stuff; either I need to try harder, or we need to
accept that since this is how people think of links being used,
we might as well bite the bullet and explain things in terms
of display.

Henry:
>One useful point this throws up is that in the case of NEW and
>REPLACE, the target resource better be a single element == a single
>node, whereas for INCLUDE it can be a sequence thereof 

Why?  I agree that there are problems in dealing with the concept of
"the result of a traversal" when the resource you're starting with
is linked to 11 others; and this is a problem we're going to have
to consider.  Strategies we might consider include

[a] ignoring the problem, leaving it to the user-agents
[b] creating another axis of behavior for use in specifying 
    multi-resource traversal behavior - note that HyTime has lots of
    this machinery
[c] saying that for xml's purposes, traversal to more than one 
    resource is never required
[d] saying that for xml's purposes, traversal to all other
    resources is always required

but when you get down to it, I think that whether the result of
the traversal is one or many resources, this is kind of orthogonal
to the SHOW issue; i.e. do you put your "new stuff" in the existing
context, or replace the existing context, or create a new context?

This final question remains, I think, a good question, one that
providers are going to want to answer, and one that I think we should 
provide machinery to support.

Cheers, Tim Bray
tbray@textuality.com http://www.textuality.com/ +1-604-708-9592

Received on Monday, 3 March 1997 20:37:50 UTC