Re: XLink and XSL...

Subject: Re: XLink and XSL...
From: Chris Maden <crism@xxxxxxxxxxx>
Date: Wed, 24 Feb 1999 12:00:09 -0500 (EST)
[Guy Murphy]
> Is anybody looking at how XLink might be integrated with XSL?

That would be me.  Others, too.

> Given that the navigation metaphor is often a major part of a Web
> site UI, and in the future XLink (or XLink-like mark-up) as a
> resource external from an XML document might we the method of choice
> for a lot of designers, I think this might be of great import to
> XSL.
> 
> I haven't looked at XLink in any great detail (intend to try and
> correct that this week-end), but are we going to have to look at a
> mechanism for XSL to combine or take two input trees? Or do we have
> to wait on XML parser support for XLink directly.

One important requirement for XSL is a means of addressing link ends.
It's a hard problem, though, because a link end doesn't necessarily
nest properly in the element structure.

> If it's an XSL concern then a mechanism can probably be produced
> that will have application beyond XLink. If it's an XML parser
> concern then we might end up with a highly specific solution.

Linking should be at a layer above the parser.

[Simon St. Laurent]
> 2) Using XSL to present links (display issues) and preserve link
> information across a transformation

The first problem, styling, is very hard.  A paper discussing some of
the problems can be found at
<URL:http://www.oreilly.com/people/staff/crism/xsl/linkreq.html>.

Preserving link information across a transclusion isn't hard if the
links are in the document.  But keeping extended linkends that are
stored in another document is tough, because the link document won't
be pointing at the result of the transformation, most likely, and
inlining the previously out-of-line links could be a nasty bit of work
given the fact that the link ends (as previously mentioned) may not
align with element boundaries.

> 3) Using XSL to determine the traversable paths in a link
> relationship, which are left undefined in XLink extended links.
> (Extended links are just a set of resources, not something you can
> traverse like a simple XLink or an HTML link.)
> 
> All of these are important.  #3 is a hassle, since it seems to leave
> XLink dependent (in my view) on a style sheet system that many
> applications will find to be useless overhead (i.e., those that
> don't actually display the links or perform any other
> transfomations).  Of course, I've been shouted down on that point a
> number of times on xlxp-dev.

#3, to my mind, is necessary.  Without it, there's no flexibility.

There must be the ability to style a link where XLink wasn't used, for
instance in ID/IDREF situations.  Since that's a requirement for XSL
anyway, it makes sense to use that same capbility for XLink links
rather than duplicating the functionality.  The real problem is
identifying the link ends from within the stylesheet.  With HTML and
CSS, I'll color different kinds of links differently; I should be able
to do at least that in XSL, plus generating text or transforming the
link in some way.

Another problem that we've become aware of since I wrote the paper is
identifying the canonical location of an element.  An XPointer locates
an element, not its styled result.  So if an element is instantiated
twice in a styled document (as a simple example, a chapter title that
appears both at the start of the chapter and in a cross-reference),
where in a styled document does traversing a link take you?  In some
cases, a human can tell easily, but in the general case, how can the
problem be solved?  I need to update the paper, I think.

-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


Current Thread