Re: XLink support in XSL

[Simon St.Laurent]

> 1) Is this really a task for XSL?

Well, deciding how to present information is what I call styling.
Whether the styling of links should be done in the same place as the
styling of elements and text is certainly debatable; I think it
should.

> Are applications that aren't concerned with presentation in the
> formatting/tranformation world going to need to cope with all of XSL
> just to manage a few links?  (Will this be a subsettable operation,
> so that you don't need all of XSL, or are developers going to be
> stuck with the whole damn thing?)

I think they will, because you don't know what's a link until you've
got the formatted document.  Certainly things marked with XLink are
links; but what about IDREF pointers?  What if my stylesheet finds all
occurrences of certain words and turns them into links?  An
application that does something interesting with links should probably
know about those.

> How does it relate to formatting objects?

The formatting objects are a way of presenting information to a user
(be it human or robotic).  The thing-you-click is presentational; it
represents an informational relationship, just like the thing-that-is-
bold represents some kind of information about that element.

> 2) Does XSL have any way to cope with styling across multiple
> contexts and documents? Simple example: I load document A, which has
> a link (A, B, C).  A's style sheet says to create traversal paths
> A->B, B->A, A->C, C->A.  I go to B, and its stylesheet interprets
> the link as B->A, B->C.  I go to C, and its owners don't want anyone
> annotating, so they've specified that no links from outside the
> document should be accepted.  User X has their own style sheet that
> they slap on top of all this with yet a different interpetation.
> Making multidirectional links robust enough for the Web is going to
> require some heavy rule-making.  'Persistence' - necessary for
> multidirectional linking and hub groups - brings up some very odd
> issues that need to be addressed.

This is a good question, and it hasn't been thoroughly discussed yet.
Everything has some sort of default rule; for elements, you end up
with the textual content inline.  For link ends, I'd suggest that the
default be blue underlined or outlined clickable objects in GUI
browsers, and numbered selectable bold text in Lynx.  In other words,
that they be hot.  The stylesheets in effect might specifically handle
certain link roles, while others would receive the default behavior,
or have only the color changed.  An author's stylesheet might
expressly turn off linking from a document, but the user's stylesheet
or the browser's built-in one[*] might well override that.

There is an interesting question in "the stylesheets in effect": which
are those?  Does the stylesheet of the document in which the link
occurs take effect?  The stylesheet of the document in which the link
end is found?  Do they cascade together?  It's a tough question.  You
have the potential for clashing roles, since that space (I can't call
it a namespace any more...) is completely ungoverned.  But I firmly
believe that no subject can't be analyzed to death or boredom. (-:

> 3) Is CSS going to provide similar support?  (I realize that's not
> completely relevant to this list.)

CSS already has some simple support in its :link pseudo-element and
kin.  It doesn't have explicit XLink support in accessing qualities of
the link or link-end, but it can match followed, unfollowed, or active
links.

That's all from me!  I'm leaving soon for a week, and I can't afford
to spend any more time on this before I go away.  So don't say
anything interesting please!

-Chris

[*] Which, remember, need not be actually instantiated as an XSL or
    CSS document.
-- 
<!NOTATION SGML.Geek PUBLIC "-//Anonymous//NOTATION SGML Geek//EN">
<!ENTITY crism PUBLIC "-//O'Reilly//NONSGML Christopher R. Maden//EN"
"<URL>http://www.oreilly.com/people/staff/crism/ <TEL>+1.617.499.7487
<USMAIL>90 Sherman Street, Cambridge, MA 02140 USA" NDATA SGML.Geek>


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