[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Fwd: RE: James Clark: XML versus the Web
Kurt Cagle XML Architect Lockheed / US National Archives ERA Project ---------- Forwarded message ---------- From: Kurt Cagle <kurt.cagle@gmail.com> Date: Wed, Dec 15, 2010 at 11:57 PM Subject: Re: 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:
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:
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] |
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
|