XLink: behavior must go!

["Martin Bryan" <mtbryan@xxxxxxxxxxxxxx>]

Paul Prescod wrote:

>I believe that the XLink behavioral attributes should be removed.
Theoretically they mix presentation and structure. This causes all kinds
of practical problems addressed below:

Behaviour *must* stay. What we need is some mechanism for passing through
behaviour control properties from the instance to the XSLT. 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. In fact the behaviour attribute should move from the
XLink to XML standard, as xml:behaviour-control, but that is is bit too
radical for people to bite off just yet. In the meantime it is vital that at
least XLink provides us with a standardized mechanism for controlling
instance behaviour. (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.)

>We could go whole hog and specify exactly what they look like (e.g. popup
menus, buttons, hotlinks, etc.) and provide options for styling them. But
that would further violate a major tenet of the XML religion: the
separation of presentation and structure.

No we could not! In the first place XSL is 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. 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"?  You cannot predefine the
behaviour of all (or any) XML document instances - you can only provide an
extensible mechanism that people can use to indicate what type of behaviour
may be required and what controls should be used for this purpose within the
XSL processor.

>Take all references to behavior and traversal out of the XLink spec. Move
it all into a pair of specification called "Extensions to XSL for Link
Rendering" and "Extensions to CSS for Link Rendering."

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. One type of
behaviour I would like to see is to be able to control which stylesheet
should be associated with a particular instance when traversed via a
particular linked document. As it stands authors have no control over the
presentational style of a non-embedded instance. (This is a great agrument
for auto-embed as it allows the display of the recalled data to be
controlled by the local stylesheet.) We need a better mechanism for choice
of stylesheet than those currently being shown. For example, I would like to
be able to select the stylesheet used based on the language setting of the
user's locale. How can I do this? We desparately need mechanisms to manage
both link behaviour and the behaviour of stylesheets associated with linked
documents. 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.

Martin Bryan






 XSL-List info and archive:  http://www.mulberrytech.com/xsl/xsl-list