[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

Re: XLink transformations

• From: "Simon St.Laurent" <simonstl@s...>
• To: xml-dev@x...
• Date: Tue, 18 Jul 2000 10:41:41 -0400

At 06:18 PM 7/17/00 +0200, Michael Kraus wrote:
>I'm currently working on an XML/XSL/XLink Browser
>(http://www.pms.informatik.uni-muenchen.de/lehre/projekt-diplom-arbeit/brow
ser-toolkit.html)
>and have the following problem: The Browser takes as input an XML file,
>an XSLT stylesheet and an XLink linkbase. The links refer to elements in
>the XML file, of course. Now, if the XML file is translated into FO (or
>HTML), how can the browser know to which element(s) a certain XLink
>refers?
>
>There are two different levels: data and presentation. the XML and XLink
>files are on the data level, and the FO (HTML) file resulting from the
>XSLT transformation is on the presentation level. But this file
>represents the transformation of the XML file ONLY! How is it possible
>to transform the XLinks as well?

As Ben Trafford notes, this is a problem which has been around for a long
time (on various XLink lists, XSL-List, and xml-dev), but which no one's
really solved sufficiently.

I'd like to point out that this is a case where CSS may have a sizable
advantage over XSL, as CSS doesn't have to manage multiple trees.  Opera's
already done some very basic work in this regard that I used to support
simple XLinks:
http://www.xml.com/pub/2000/04/19/opera/index.html

The W3C also has an apparently contentious draft of 'CSS behaviors' at:
http://www.w3.org/TR/becss

A lot of this draft (the HTML Components part) is just plain awful, and not
relevant, but CSS behaviors and scripting might well be able to handle even
the complex linking cases by themselves, or at least adequately supplement
an XLink-aware browser.

(It's worth noting that various discussions Paul Prescod and I raised about
these issues on style mailing lists haven't gone much beyond Paul and
myself, and that was long ago.)

I suspect that we're going to have to think of XLink in multiple parts.
First, a syntax; then, a processing model.  I don't think we have the
implementation experience yet to understand how this will interact with
other specifications - stylesheets in particular.  My own XLinkFilter
(which desperately needs an update) deliberately avoided such interactions
for the sake of providing a very simple core for small applications.

Hyperlinking has always been something of a hydra, and I'm afraid that the
delays on XLink have left it a sleepy hydra.  On the other hand, the spec's
a lot better than it was....

Simon St.Laurent
XML Elements of Style / XML: A Primer, 2nd Ed.
http://www.simonstl.com - XML essays and books

• Follow-Ups:
  • Re: XLink transformations
    • From: Ben Trafford <ben@l...>

• References:
  • XLink transformations
    • From: Michael Kraus <michael.kraus@i...>

• Prev by Date: RE: XLink transformations
• Next by Date: RE: XLink transformations
• Previous by thread: Re: XLink transformations
• Next by thread: Re: XLink transformations
• Index(es):
  • Date
  • Thread