3.1 b-h: BEHAVIOR

 Dimension 1: Which pieces of information should be specified for
 possible inclusion in linking elements?
 ...
 f. behavior
 ...

This one has been tough.  Since we put in immense amounts of time, I will
try to reproduce some of our discussions.

Some of the options:
a. say nothing about behavior; leave it to the apps and to stylesheeting
b. provide a behavior bucket; an attribute in which to pass behavior info,
   but specify nothing about what goes in there
c. provide one or two attributes governing simple abstract axes of link
   behavior policy, with lots of room for user-agents/clients to devise
   mechanisms to meet the policies
d. provide a rich, detailed, set of behavior specification rules that
   people such as users of EBT products, TEI, and HyTime have come to
   expect.

(a) and (b) seem the safest in terms of avoiding doing something really
stupid.  However, there was stringent opposition from those speaking
on behalf of the authors, who wanted some (even if only abstract) way
to signal whether a link, when activated, should cause the replacement
of the current display, or transclusion behavior; they claimed that without 
this, there was no interoperability.  It is also material that on the WWW, 
there are at least two well-defined link behaviors, that of the <A HREF= 
and that of the <IMG SRC= in the HTML case, accomplished by associating 
application semantics with well-known GI's.  Also, perhaps <FORM ACTION= 
is really a link?

(d) is probably the right thing to do, had we but world enough and time,
but also carries a lot of risk in terms of overspecifying and getting
things wrong.

So, we ended up with (c). The ERB consensus is that there will be two
attributes specified to control behavior; the names and values given 
below are provisional.

Each attribute may be provided per-linking-element or per-resource; while
there was a sense that per-linking-elements could probably be used to
provide defaults, and be overriden by per-resource elements, this was
not discussed thoroughly, nor really voted on.

There will be an attribute named SHOW, which may have one of three values:

INCLUDE - means that upon traversal of the link, the indicated resource 
 should be embedded, for the purposes of display or processing, in the body 
 of the resource where the traversal started. (e.g. like HTML <IMG)
REPLACE - means that upon traversal of the link, the indicated resource
 should, for the purposes of display or processing, replace the
 resource where the traversal started. (e.g. like HTML <A)
NEW - means that upon traversal of the link, the indicated resource should
 be displayed or processed in a new context, not affecting that of the
 resource where the traversal started (e.g. like HTML <A TARGET="NEW" [I 
 think])

There will be an attribute named ACTUATE, which may have one of three values:

AUTO - means that the link should be traversed and used when encountered;
 that the display or processing of the resource where the traversal
 started is not considered complete until this is done (e.g. HTML <IMG)
USER - means that the link should not be traversed until there is an
 explicit external request for this to happen (e.g. HTML <A)
PUSH - means that the resource is volatile, subject to change, and 
 should be processed immediately and continuously.

Notes:
 a. HTML <A is equivalent to SHOW="REPLACE" ACTUATE="USER"
 b. HTML <IMG is equivalent to SHOW="INCLUDE" ACTUATE="AUTO"
 c. Obviously, it is legal for user-agents to ignore these settings and
    do as they will; for example, turning image loading off.

With reference to the values of the ACTUATE element, it may be 
possible to use the event names that are being proposed for use in
the W3C's work in progress on the "Document Object Model"; we have
an action item to check this out and do so if possible.

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

Received on Saturday, 1 March 1997 21:38:56 UTC