Re: XLink transformations
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
PURCHASE STYLUS STUDIO ONLINE TODAY!
Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!
Download The World's Best XML IDE!
Accelerate XML development with our award-winning XML IDE - Download a free trial today!
Subscribe in XML format