---------- Forwarded message ----------
From:
Kurt Cagle <kurt.cagle@gmail.com>
Date: Wed, Dec 15, 2010 at 11:57 PM
Subject: Re: [xml-dev] RE: James Clark: XML versus the Web
To: Henri Sivonen <
hsivonen@iki.fi>
Henri,
To clarify here - if you have an XSLT transformation object, depending upon the particular implementation, you can typically compile that XSLT into a specific processor, apply relevant source nodes to that processor, and the utilize the output of the transformation as nodal content (typically associated with a given HTML node).
In Chrome, Firefox and Safari, you have the XSLTProcessor() object, which can be used to define content as follows:
xsltProcessor = new XSLTProcessor();
xsltProcessor.importStylesheet(xsl);
xsltProcessor.setParameter("","myParam","myValue");
resultDocument = xsltProcessor.transformToFragment(xml, document);
document.getElementById(InsertElementId).appendChild(resultDocument);
where xml in this case is the source to transform and document represents the document context that the result will be transformed into. Additionally, you can set parameters and modes on the xsltProcessor using the xsltProcessor.setParameter() and xsltProcessor.setMode() functions. In order to do incremental updates, typically you'll end up binding the XSLT processor once (typically at load time) and make it available as a global object, then you can take that object and pass in different nodes for different specific operations, or modify the parameters in order to change the interpretation of the transformation. The implementation is similar but not identical on IE - you'd have to look up the API.
I'd frequently wrap XSLTProc calls within XBLs in order to build complex tag components, both in HTML and XUL (back when I was doing Firefox development, which has admittedly been a while ago). The transformations are usually considerably faster than trying to build complex elements piecemeal in JavaScript, since you didn't need to reparse serialized strings after you'd done the initial XSL load, and you were then just attaching a child node to a parent within the HTML DOM.
A common XSLT2 implementation in the browsers would open up considerably more capabilities: the modularization capabilities of XSLT1 were relatively limited, but are MUCH richer in XSLT2, and XSLT2 supports sequences (which makes it possible to work with multiple documents simultaneously), regular expression filtering and support, code-point control, user-defined XPath functions, and rich data type support, among a number of other features.
Kurt Cagle
XML Architect
Lockheed / US National Archives ERA Project
On Wed, Dec 15, 2010 at 11:01 PM, Henri Sivonen
<hsivonen@iki.fi> wrote:
On Dec 15, 2010, at 17:20, James Clark wrote:
> On Thu, Dec 16, 2010 at 8:05 AM, Henri Sivonen <
hsivonen@iki.fi> wrote:
>> XSLT hasn't been designed for maintaining a continuous and incrementally updating relationship between the input and output trees.
>
> Not true (at least for XSLT 1; can't speak for XSLT 2). This is exactly what you need for an XSLT-driven XML editor, which was certainly one of the things XSLT was designed to enable. It is the reason why certain useful features were left out of XSLT (result tree fragments as node-sets). There have been implementations of this.
Which implementations support a reflecting incremental input updates in the output? Given everything that XSLT lets you do, how can the contribution of a piece of input to the output be tracked in a practical way?
--
