![Overview ,[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object]](data:image/gif;base64,R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7)
Recommended
More Related Content
Similar to XML Prague 2005 EXSLT
Similar to XML Prague 2005 EXSLT (20)
Recently uploaded
Recently uploaded (20)
XML Prague 2005 EXSLT
- 1. EXSLT Facilitating the Standards Process
Editor's Notes
- Working with Result Tree Fragments The exsl:node-set function returns a node-set from a result tree fragment, allowing for single stylesheets to perform multiple pass type processing. Many developers were tearing their hair out working around this limitation of XSLT 1.0. Specifically an RTF is what gets returned when using xsl:variable and since no further operation could be performed on an RTF it was necessary to convert to a first class node-set using third party functionality. The reason for such a limitation on xsl:variable was mainly implementator driven who argued that it would make their XSLT Processor development more difficult. Unsurprisingly most major XSLT processors already had their own extension functions for this, albeit with different signatures. EXSLT normalised node-set function usage, making stylesheets portable as well as to refactor complex transformations into sequences of simpler transformations. This approach was so successful that XSLT 2.0 eschews with the need of node-set function, by introducing the concept of sequences. XSLT is not a programming language XSLT 1.0 lacked a lot of functionality which one would expect from a programming language, though of course.... it was and still is never meant to be a full blown computer language. EXSLT Date and Time and Math modules provided a lot of missing functionality for developers. A lot of this common functionality has been refactored out of XSLT 2.0 all together and placed into a separate specification all together, e.g. XQuery 1.0 and XPath 2.0 Functions and Operators; keeping XSLT focused on what it was meant to be, whilst providing developers with much needed functionality. Abstracted complex XSLT The EXSLT Set module was one of the few Modules which could be implemented fully using pure XSLT 1.0 templates. The templates themselves are quite arcane and a good example of XSLT that most new users have problems with. XSLT 2.0 does a great job at getting rid of this type of 'black magic'. By encapsulating templates into callable functions, developers stylesheets become more readable and easier to understand. Early on in capturing XSLT 2.0 requirements it was obvious the need for simplifying grouping and set manipulation, which has reflected an host of features in XSLT 2.0. Outputting Multiple Documents XSLT 1.1 included some useful functionality, for example, in section 16.4 Multiple Output Documents it defined a method of allowing a single stylesheet transform to generate multiple documents. Having the ability to generate several output documents was something developers definitely wanted. Though with the August 2001 release of XSLT 1.1 stating that the W3C no longer supported that draft it was clear that this was a good function to be included into EXSLT. XSLT 2.0 supports this natively with the xsl:result-document instruction. Evaluating XPATH EXSLT also solved another nagging problem in XSLT 1.0, that of dynamically evaluating XPATH statements. The Dynamic module let developers create XPATH expressions from strings, allowing them to be constructed 'on the fly'. Controversially, XSLT 2.0 does not include this functionality, though the ability to use more sophisticated FLWR type expressions meant one didn't have to resort to dynamic evaluation techniques quite as often. String Handling XSLT 1.0 had anaemic string handling facilities; the EXSLT String and Regular Expression modules went some way to giving tools to developers to perform sophisticated string manipulation operations. XSLT 2.0 directly adopted regular expression handling and a whole spectrum of new string handling functions were defined for use by XSLT 2.0.