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

Re: XLink transformations

  • From: Ben Trafford <ben@l...>
  • To: xml-dev@x...
  • Date: Mon, 17 Jul 2000 12:01:38 -0700

xlink browser

At 06:18 PM 7/17/00 +0200, Michael Kraus wrote:
>I'm currently working on an XML/XSL/XLink Browser
>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
>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


Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!

Buy Stylus Studio Now

Download The World's Best XML IDE!

Accelerate XML development with our award-winning XML IDE - Download a free trial today!

Don't miss another message! Subscribe to this list today.
First Name
Last Name
Subscribe in XML format
RSS 2.0
Atom 0.3

Stylus Studio has published XML-DEV in RSS and ATOM formats, enabling users to easily subcribe to the list from their preferred news reader application.

Stylus Studio Sponsored Links are added links designed to provide related and additional information to the visitors of this website. they were not included by the author in the initial post. To view the content without the Sponsor Links please click here.

Site Map | Privacy Policy | Terms of Use | Trademarks
Free Stylus Studio XML Training:
W3C Member
Stylus Studio® and DataDirect XQuery ™are products from DataDirect Technologies, is a registered trademark of Progress Software Corporation, in the U.S. and other countries. © 2004-2013 All Rights Reserved.