XLink: behavior must go!

[Paul Prescod <paul@xxxxxxxxxxx>]

This probably isn't the best week to send this but you can't always choose
when inspiration (or religious fervor) will come to you. The message is
widely crossposted because it crosses disciplines but I would like to see
discussion be restricted to XML-DEV or offline. (I choose XML-DEV over
xlxp because more people are subscribed there right now.

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:

 Problem: No data model. No processing model.

In my experience, the most useless language features are those where the
interpretation is completely up to the software. The most useful features
are those that either have a well defined underlying data model *or* a
well-defined processing model. XML notations are useless not because they
are a bad idea but because nobody has defined the data model or processing
implications of the associated system identifier.

The XLink behavior attributes have this problem. Just what do these
behaviors *do*? What do they look like? They take us half-way down the
path to inline presentation and arguably that is worse than taking us down
that path whole hog. What does it look like to traverse a multi-ended
link? How are the anchors represented? Do Netscape and Microsoft get to
decide? After working for years to give them pixel-perfect stylesheet
languages are designers back to trusting that vendors will give them a
reasonable rendition?

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. 

 Problem: media dependence

That this is already a problem can be demonstrated by trying to imagine
what it means to do an "auto/replace" in a printed document or
"auto/embed" in a command-driven text-based user interface.

 Problem: stylesheet interoperability

if XSL and CSS define to the pixel what the rendition of a document in a
graphical browser should look like then what room is there for the
browser's automatic anchor display behavior? Can they insert icons or
buttons that adjust the flow? Can they override colors specified in the
stylesheets? There are dozens of little issues like this where the
stylesheet and the built-in linking behavior have the possibility of
conflicting. Who wins? What are the rules? Do we have to add a concept
like CSS's cascade to XSL?

 Problem: traversal path

the behaviors are attached to *anchors* but the correct behavior probably
depends both on the source and target anchors.

The XLink specification says: "Link formatting and link behavior are
inextricably connected" but then goes on to disconnect them. What will
happen when we try to reconnect them?

 Problem: heresy

Even if we could attach behaviors to both the source and target, the
document is the *wrong place to do it*. We don't put "FONT" elements in
our documents because the right font depends on the context of the viewer.
Well the right link behavior also depends on the context of the viewer.
Some viewers will have low-bandwidth connections and will want to
explicitly initiate embedding. Some viewers will have sophisticated tree
browsers an will want to treat what the author considered a "replace"
links as an "embed".

I have used browsers that treat HTML IMGs as "user/embed" (NS,IE images
off), "user/new" (user-invoked helper app), "auto/embed"(NS,IE default)
and "auto/new" (auto-invoked helper app). Obviously the right one depends
on the situation. Other combinations might also make sense in some
situations.

I have used user agents that treat HTML "A"s as "user/replace"(typical),
"user/embed" (Documentor), "user/new"(www-Emacs), "auto/new" (site
downloaders).

We've got to move this stuff to stylesheets so that people can make
stylesheets that are optimized for various media.

Even if we ignore UA-display and bandwidth limitations there are lots of
other reasons to have anchors behave differently based on the stylesheet.
I think three different site designers and/or end users could all disagree
on whether the best way to handle a reference to an item in the glossary
is an inline expansion (keeps context), a new window (screen clutter) or a
replace. Maybe someone new to the topic would like every glossary entry
expanded inline by default. Maybe some people want the glossary entry to
pop up when the mouse moves over it.

Another example: perhaps one view of some document is for "textual" people
(pictures on demand) and another for "visual" people (pictures inline).

 Problem: incompatible implementations

Okay, so to get around the fact that the client will and should do
whatever it wants, we could refer to the links behaviors as just "hints".
"Hints" are a sure sign that something is wrong in language design. They
are usually an excuse for not doing the right thing. In this case, the
right thing is to move all behavioral specifications into the stylesheet.

Web designers should run screaming from underspecified behavioral
attributes of all types. They are still trying to clean up the mess left
by the (unavoidable) delay between the creation of HTML: "trust your
browser" and CSS: "designers know better than software engineers." The
behaviors chosen by browser authors were not always interoperable and then
when we tried to "layer" the CSS standard on top it became a total mess
because the "built-in" stylesheets of various browsers were different. The
only way to get 100% portable rendering is to carefully and completely
override the built-in behaviors of the browsers. So what is the use of the
hints then?

Also, XLink's behavior attribute is a car-wreck waiting to happen. What if
Microsoft and Netscape use it differently?

 Problem: confusion

Many, many people want to interpret the auto/embed command as an
instruction to embed the nodes at the target at the current location and
thus do node reuse. But this interpretation is not supported by the XLink
specification. The target of an auto/embed could be a language that has no
concept of "nodes" (barring definition of grove property sets) such as a
JPEG or MPEG.

Furthermore, I've thought about making a transclusion syntax for XML and
there are some hard problems that XLink has not solved. For instance what
if IDs clash. What happens to pointers and links? etc.

The specification also suggests that auto/replace can be used for
forwarding. To me this is just further evidence that these attribute are
medium-specific presentational tricks. Is AltaVista or Google supposed to
recognize an auto/replace as a request to update the entry for a document?
The argument that these are "invariant semantics of link types" does not
strike me as a good one. There is nothing semantic about "when you click
here you go there." That's all about behavior.

 Problem: non-sensical combinations

What if a document has a hundred anchors that all have auto/replace?
Should it open a hundred documents in the current window *one at a time*?

 Problem: complexity

Let's radically simplify the XLink specification and *get it out the
door*. Taking behaviors out will help.

 Solution:

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."

In CSS, the basic model would be that link anchor-handling rules would be
processed as part of the cascade. The "ordinary" rule might make some text
bold and the "linking" rule would make it blue, underlined and clickable.
Some simple rules could also render extended links as popup menus, lists
of buttons, lists of icons, etc.

In XSL, the model would be that link anchor-handling rules would have a
higher priority than ordinary rules (either in general or through manual
priority setting). They would specify some details of formatting and
behavior (e.g. underline and clickability) and then invoke the rules that
would otherwise have applied (e.g. to actually process text and
sub-elements). Merging of adjacent clickable links can occur in the
back-end. (e.g. <LINK DEST="foo">blah blah blah</LINK><LINK
DEST="foo">blah blah blah</LINK> would be rendered as a single link).

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

Diplomatic term: "Emerging Markets"
Translation: Poor countries. The great euphemism of the Asian financial
             meltdown. Investors got much more excited when they thought 
they could invest in up-and-comers than when they heard they could invest 
in the Third World.(Brills Content, Apr. 1999)


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