Re: CSS and XLink

At 02:27 AM 5/6/99 +0100, Ian Hickson wrote:
>As I understand it, a `link' presumably has to include the following
>information:
>
>   A set of n resources (where n > 1)
>   The relationships between the resources

Pretty much, though the tools for describing the set and the components are
sort of odd.  There are element names - XLink does its magic through
attributes - which may or may not be useful.  There are roles, which
describe components "to identify to application software the part it plays
in the link" and behavior, which describes "Behavior politicies to use in
traversing to this resource."

(You can also have a set of resources where n=1, but that's an odd case and
traversal isn't really an issue there.)

>The "relationship" is the equivalent of the HTML "rel" and "rev"
>attributes, although obviously more powerful.

More powerful, and simultaneously more obfuscated because rel and rev only
connect two resources at a time. XLink extended links may be describing a
relationship between hundreds of resources in a set.

>Presumably the "traversal path" is "what happens when the link is
>activated", otherwise known as the link's _behaviour_. 

The problem, however, is that there is no easy way to determine which
resources actually should appear as the start or end points of said
traversal paths.  The behavior attribute may provide clues in this regard,
but we're going to have to be able to figure out what's a starting point
for a traversal path and what's an end point and which resources are both
and where you can go from here before we can 'completely' style a link.

Maybe action sheets are up to this task, but we're going to need a
framework to hang this on.

>As I see it, that and its presentation are the only things that are in
>the scope of CSS/CAS and out of the scope of XLink. Currently (as in,
>in the last draft), XLink includes some attributes (actuate and show)
>that suggest traversal path information, but does not specify how that
>is to be used. In my opinion, these attributes should be left off
>XLink, letting DTD authors decide which attributes to use and make
>stylesheets to match.

I think I'd rather they stay in, but specify that style sheets or
application features can use or ignore them at their pleasure.  Not all
XLink applications will use style sheets - I have a simple image map
application on my Web site that never goes near them.  Nonetheless, that
information (actuate and show) could be very useful to an application like
mine.

>> If the current XLink model survives - describing only sets of
>> resources, and not the paths between them, it'll be up to style
>> sheets or some other yet-built mechanism to turn links into
>> traversable paths.
>
>I have shown how this is already possible using existing proposals
>(mainly Cascading Action Sheets).

I don't think you have, actually.  In the last round, you ended with:
(http://lists.w3.org/Archives/Public/www-style/1999Apr/0024.html)
>It is my (very strongly held) opinion that path _traversal_ should be
>firmly in the XLink ball park. If it is not, then what, exactly, *is*?

We need a mechanism - a reliable mechanism at that - to be able to convert:

(A, B, C) (where A, B, C are resources annotated with behavior)
to
(A->B, A->C) OR (A->B, B->A, A->C, C->A) OR
(A->B, B->A, A->C, C->A, B->C, C->B)

or any of the other possible traversal path combinations that are possible.
 Even (A,B) can be (A->B), (A->B, B->A), (B->A), or ().  XLink opens these
possibilities but doesn't specify how to make them work.

On top of all that, there are large questions involving link persistence.
Creating multidirectional links (where you can go 'backwards' on a link,
not just use the 'back' button) implies persistence of linking information
between pages.  How do we handle that in CSS?  It's not information on the
current page, it's information on a previous page or retrieved from a link
directory that may not even have a style sheet of its own.

Lots of work yet to do here, I fear, and no sign the XLink WG wants to help
resolve traversal path issues.  (Of course, they've been very quiet for a
long time, and may have changed their minds, but given past discussions, I
doubt it.)

Simon St.Laurent
XML: A Primer / Building XML Applications (June)
Sharing Bandwidth / Cookies
http://www.simonstl.com

Received on Saturday, 8 May 1999 09:30:39 UTC