xml-dev - Re: XLink transformations

[Ben Trafford <ben@legendary.org>]

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/browser-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?

         This is a problem which plagued the XLink working group. There is 
a meeting scheduled to discuss just these issues in August, but meanwhile, 
let me share a brief overview of how my nascent XLink/XPointer 
implementation handles the problem.

         I'm viewing XLinks from the authoring side, in this instance, 
under the assumption that there are organizations who have several document 
authors (who'd be using XLinks), and one or two stylesheet authors (in much 
the same way publishers have many others, but only a few typesetters). It 
occurred to me that the authors might lose their links if a stylesheet 
writer made a mistake in his stylesheet that inadvertantly transformed the 
XLinks out of existence.

         So, my engine tracks the XLinks, and has a warning flagged if they 
disappear during transformation. That warning may, or may not, be passed to 
the authoring or viewing application.

         In terms of directly transforming XLinks, well, XSL doesn't handle 
the full range of XLinks natively. It seems that the transformations which 
aren't handled by FOs should be done prior to stylesheet-based 
transformation. For example, 'onLoad' links would be automatically 
included, prior to document transformation.

         There are interesting issues around recursion of links (what 
happens if I call a document that calls a document that calls a document, 
and so forth) and what stylesheet properties to include (what happens when 
I call a document with its own stylesheet, does mine override it? What 
happens when the two documents share the same element names?). I've 
resolved the former issue with a simple error catching if too much 
recursion happens (and recursion levels can be set as a variable in the 
tool), and the latter using a fairly complicated scheme where onLoad 
documents are brought in with their stylesheet declaration and some nifty 
namespace magic.

         Anyhow, sorry to be so general, but I'm still discovering the 
solutions to these problems myself. It's a fairly scary can of worms, that 
underlines the need for some sort of overall processing model for the 
interaction of various XML-based standards.

--->Ben Trafford