XLink: behavior must go!

[Paul Prescod]

Martin Bryan wrote:
> 
> Behaviour *must* stay. 

Behaviour in general, yes. Behavior attributes in XLink? Not in my
opinion.

> What we need is some mechanism for passing through behaviour 
> control properties from the instance to the XSLT. 

XSLT already has features for retrieving attributes. We don't need to do
anything special for behavior. From my minimalist point of view the only
extensions we need for XSLT are the ability to recognize and traverse
anchors and links and the ability to control flow between a linking
template rule and an ordinary template rule.

> The behaviour
> attribute provides us with a standardized point which we can query from
> within XSLT to determine which types of behaviour a particular 
> instance of an object should have. 

The XSLT is inherently tied to a document type. So why would we need to
standardize the attribute name used for specifying behavior? There is no
problem if you want to call it martin:behavior and I want to call it
paul:behavior. In fact, that is good, because you can call it
"popup_yes_or_no" and I can call it "javascript_command" depending on the
semantics of our respective document types.

The last thing we want is to have a single attribute called behavior where
you put "yes-popup-it-up" and I put "this.popup()" and to have browsers
trying to guess the semantics of the behavior attribute. We should either
standardize it completely or not at all.

> (Paul is right to say this is really a "hints"
> thing -but it is something more than a hint - it is a set of parameters that
> can be used to control behaviour where appropriate.)

In most document types it is *not* appropriate for the author to control
behavior directly at all for exactly the same reason that it is not
appropriate for them to control presentation (which is really a kind of
behavior anyhow). In the minority where it is appropriate you can either
use adhoc mechanisms like those described above ("popup_yes_or_no") or
even define standards built on top of XLink ("BehaviorLinks").

We have to be very careful what goes in which level. You want xml:behavior
in XML. Someone in the XSL list wants xml:script. Typographers are going
to want xml:font. All of these are specific to either a particular
document type or maybe a set of document types and should be specified in
higher layers.

> No we could not! In the first place XSL is not defining a GUI. 

In what sense is XSL not defining a GUI?

> In the second
> we could not begin to guess what the *user* requires. What if the user is
> blind? None of your suggested behaviours would be of the least use.

That isn't true: popup menus are meaningful to blind people. But even so
we could have other hotspot object types for other media. That's exactly
why we have to move it into a stylesheet.

> What if
> the behaviour said "convert this instances of of invoices to
> euros before display" or "use the current exchange rate to express any
> prices in the linked document in the user's local currency"? What
> if the behaviour said  "If this instance of the message is selected do > not allow
> the user to select another of the listed options"?  

XSL has extension mechanisms both in the XSL transformation and (I think)
in the generated document.

> Again its a question of who is in control. We need to leave 
> authors with the right to make choices without having to be 
> stylesheet designers. 

You sound like the people who tell me that XML sucks compared to Word
because it takes control away from the author. Usually taking away control
is the goal. Then you give back control in the stylesheet. That's the
whole basis for descriptive markup.

If, in some particular case, you need to put control right into the
document type you do that by creating a stylesheet that puts the right
level of control in the document. Nothing stops you from making a <blue>
element type or a <javascript_behavior> element type. Just don't put
either in the core language (or linking language) please!

> One attribute to do this, rather than a whole set of customizable
> ones that change from environment to environment is the only way we are
> going to get transportable interactive documents.

You and I agree that various document types have differnet behavioral
needs. We agree that there is no way that we can define everything that
needs to be done in advance. I think that we agree that usually behavior
should be defined in stylesheets, though there are a few cases where it
should be defined inline. You demand that when it is inline it should
always be expressed in the same attribute. I claim that this will
interfere with the goal of extensibility and interoperability. 

It would be like requiring every XML document type to have a "para"
element type. If we disagreed on the meaning and structure of paragraphs
(which we inevitably will) then the common element type name is useless.
Some people will be lulled into thinking we have interoperability but when
we actually try to apply our stylesheets or programs to each others
documents they would crash.

Instead, we should all choose our own names for paragraphs and the mere
act of making that choice will make clear that we are actually expecting
our paragraph types to have different *content*.

Same with the behavior attribute. We should only have common attributes if
we can decide in advance what the structure of the content will be.
Otherwise let's not present an illusion of interoperability.

-- 
 Paul Prescod  - ISOGEN Consulting Engineer speaking for only himself
 http://itrc.uwaterloo.ca/~papresco

Earth will soon support only survivor species -- dandelions, roaches, 
lizards, thistles, crows, rats. Not to mention 10 billion humans.
	- Planet of the Weeds, Harper's Magazine, October 1998



xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev at ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1
To (un)subscribe, mailto:majordomo at ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo at ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa at ic.ac.uk)