Re: XLink and XSL...

Subject: Re: XLink and XSL...
From: Guy_Murphy@xxxxxxxxxx
Date: Thu, 25 Feb 1999 11:20:25 +0000
Hi Chris.

I may well have gaps in the area of linking (if so be kind :), I certainly
haven't considered all the permutations XLink brings to document
presentation, or we may simply be missing each others intent here

Firstly, there are definately mechanisms that need to be worked through to
allow user agents to manage and work with complex linking, but that isn't
really what I'm after here (although I'm sure I will be as my grasp of the
area broadens).

What I'm concerned with is mechanisms that allow *me* to work with extended
links from XSL as to produce in dHTML my interpretation of the link

You say that linking should be layered above the parser, and I'm not quite
sure what you mean by this. As I see things currently XLink is just data
that's linked to a document as a resource, all I want is to be able to work
with that data from XSL.

On the subjest of preserving extended links across transclusion, I'm not
sure that this is any different from documents with dynamic inclusion
compared to wholy specified documents, at the end of the day unless the
transformative process can write result to both the result document and
another document maintaining the extended links, this linkage straight out
dies and forces specify links in the result document if you want them

Hmmm, maybe rather than suggesting that XSL should be the active process in
aggregation I should shift to your terminology and suggest that XSL should
be the active process of transclusion. If XSL supports multiple inputs and
multiple outputs then all XLink becomes is a common way to describe links,
as the author has the means it's up to them how they choose to manage and
present the XLink description.

Lastly you note that an XPointer doesn't point to the styled result... it
shouldn't automaticaly do so. The result is a *different* document. There
is also the concept of document ownership. You may mark-up an XML document
and if I produce an XSL stylesheet for it the result is an interpretation
of that document... *my* interpretation, and it should surely be my
responsibility to carry over any links necessary or deemed appropriate.

It may be a difference in approaches but I wouldn't term two instantiations
of an input element instead two interpratations of that element that may
indeed be a more complex, simpler construct that might differ from each
other conceptualy. Surely it's up to the XSL author to establish how
traversing a link pertains to these result elements.

In short the input document and the result document are two separate
entities. How closely they relate to one another is down to the author of
the XSL, and relationships between the two should be *facilitated* by
XLink/XPointer, not *stipulated*.

If XSL does become the active process of transclusion then the result may
have relationships with more than one preexisting documents. If XSL isn't
to be the active process of transclusion what is (surely we're not going to
rely on the user agent)?


xsl-list@xxxxxxxxxxxxxxxx on 02/24/99 08:00:09 PM

To:   xsl-list@xxxxxxxxxxxxxxxx
cc:    (bcc: Guy Murphy/UK/MAID)
Subject:  Re: XLink and XSL...

[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
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.
<!ENTITY crism PUBLIC "-//O'Reilly//NONSGML Christopher R. Maden//EN"
"<URL> <TEL>+1.617.499.7487
<USMAIL>90 Sherman Street, Cambridge, MA 02140 USA" NDATA SGML.Geek>

 XSL-List info and archive:

 XSL-List info and archive:

Current Thread