Re: XLink support in XSL

[Chris Maden <crism@xxxxxxxxxxx>]

[Simon St.Laurent]

> Actually, it's worse than this.  A contingent on the XLink/XPointer
> list wants XSL (or another style sheet-like mechanism) to actually
> determine which traverses are possible, thereby handing the task of
> 'resolving' links to the application.  This makes the 'yes' far more
> resounding - it also requires XSL (or some other mechanism) to
> develop rules for handling style sheets that operate between
> contexts.

I'm one of them.  A link expresses a relationship.  Here's an analogy:

   An element has a name, its type: it is a string with no inherent
   meaning to the application.  It has parent and possibly sibling and
   child relationships.  *That's it.* It isn't bold, it isn't purple,
   it isn't chocolate.

   A stylesheet takes elements matching a pattern, simplistically
   those whose type matches an arbitrary string, and formats them as
   e.g. a paragraph with vanilla borders and loud funk music.

You all know this: it's what stylesheets do.  But watch this:

   A link has a name, its role: it is a string with no inherent
   meaning to the application.  It has linkends, each possibly with
   their own role.  *That's it.* It isn't clickable, it isn't
   autoload, it isn't blue, it isn't underlined.

   A stylesheet takes linkends matching a pattern, simplistically
   those whose role matches an arbitrary string, and formats them as
   e.g. an inline string with a clickable icon.

Why should this be any different?  When you've identified that a
particular point in a document is a link-end (which XSL can't yet do,
but will), decide based on the roles and built-in XLink hint
attributes whether, per *your* application conventions, it should be
automatic (in which case just go and get the content, no linking
involved for the user) or if it should be an activatable link, or not
"hot" at all.

-Chris
-- 
<!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