XML Prague 2005 EXSLT


Published on

about EXSLT what we did right / wrong

Published in: Technology
  • Be the first to comment

  • Be the first to like this

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide
  • 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.
  • XML Prague 2005 EXSLT

    1. 1. EXSLT Facilitating the Standards Process
    2. 2. Overview <ul><li>Jim Fuller (jim.fuller@webcomposite.com) </li></ul><ul><li>Problem: Year 2000, portability, functionality in XSLT </li></ul><ul><li>Solution: EXSLT </li></ul><ul><li>Where we got it right/wrong </li></ul><ul><li>Benefit </li></ul><ul><li>Open Source Specification </li></ul><ul><li>Future for EXSLT </li></ul>
    3. 3. Problem in XSLT, around the Year 2000 <ul><li>XSLT 1.0 processors were implementing extension functionality </li></ul><ul><li>XSLT becoming dependent on underlying processor </li></ul><ul><li>Reduced compatibility </li></ul><ul><li>Other problems: XSLT was limited, basic usage was being hampered by RTF </li></ul>
    4. 4. History <ul><li>April 2000 Stephen Meunch </li></ul><ul><li>Don Park XTECH2000 and David Megginson (of SAX fame) </li></ul><ul><li>W3C reacted with XSLT1.1 e.g. xsl:script </li></ul><ul><li>Early 2001, Uche Ogbuji generated a petition </li></ul><ul><li>Dr. Jeni Tennison formulated a set of draft specs </li></ul>
    5. 5. Solution: Extensions for XSLT <ul><li>March 2001, Dr. Tennison and small subset of community went about defining EXSLT </li></ul><ul><li>EXSLT defines functions grouped into modules </li></ul><ul><li>Where possible we created implementations either in pure XSLT 1.0 or using javascript </li></ul><ul><li>Created documentation to assist users and implementators </li></ul><ul><li>It was hoped that XSLT processor implementators would create native implementations </li></ul>
    6. 6. EXSLT Modules <ul><li>Common: Dramatically simplified stylesheets through providing a node-set(), object-type(), and document() (as per XSLT 1.1) function definitions </li></ul><ul><li>Date and Time: A full range of date and time handling functions. </li></ul><ul><li>Dynamic: Enables dynamic evaluation of XPATH </li></ul><ul><li>Sets: Encapsulated functions which make it easy to perform set type operations on XML. </li></ul><ul><li>Functions: Enabled the creation of functions </li></ul><ul><li>Math: Enables basic math operations within XSLT </li></ul><ul><li>Random: Added facilities to generate random numbers </li></ul><ul><li>Regular Expressions: Enabled regular expression handling </li></ul><ul><li>Strings: Contains string handling functions such as tokenize() and find() / replace(). </li></ul>
    7. 7. EXSLT Implementations <ul><li>Saxon </li></ul><ul><li>4suite </li></ul><ul><li>Libxslt </li></ul><ul><li>Xalan </li></ul><ul><li>EXSLT.NET (now in Mvp.Xml) </li></ul><ul><li>sablotron </li></ul>
    8. 8. Where we got it wrong <ul><li>No one uses Function module </li></ul><ul><li>Didn’t follow Software development practices </li></ul><ul><li>Module and function level imports fundamentally broken </li></ul>
    9. 9. Function Module <ul><li>Underestimated the power of templates </li></ul><ul><li>Lots of energy went into the discussion </li></ul><ul><li>Originally intended to provide an EXSLT Function implementation of every extension </li></ul>
    10. 10. Lack of Rigor <ul><li>Placing EXSLT with sourceforge would have been smart from the beginning </li></ul><ul><li>Heavyweight XML markup allowed us to ‘get away’ with standard software development practice </li></ul><ul><li>Having no continuous integration or source control in place, very bad and paying the price today </li></ul>
    11. 11. Import XSLT <ul><li>Importing was ‘broken’…was no easy way for users to use module level imports </li></ul><ul><li>Due to the fact of importing all implementations e.g. if msxsl:script element was encountered by XSLT processor that didn’t understand the element…. </li></ul>
    12. 12. Other Nagging Issues <ul><li>Interdependencies </li></ul><ul><li>Function Submission process </li></ul><ul><li>Missed opportunities </li></ul><ul><li>Licensing </li></ul><ul><li>Namespaces </li></ul>
    13. 13. Getting things right <ul><li>Catering to users, implementators and eventually specification </li></ul><ul><li>Having individuals like Jeni Tennison and Michael Kay involved </li></ul><ul><li>Extensive documentation </li></ul><ul><li>Inclusion of use cases </li></ul>
    14. 14. Lessons Learned managing a large XML distribution <ul><li>Large XML distributions benefit from the re-use of existing markup/vocabularies like RDF and Dublin Core </li></ul><ul><li>Just because its markup doesn’t mean ‘give up software development practices’! </li></ul><ul><li>RDF made revision easy everywhere </li></ul><ul><li>Didn’t need typing / XML Schema…though next time around… </li></ul>
    15. 15. Some Ruminations <ul><li>EXSLT was created by the entire XML community </li></ul><ul><li>As with success on software projects, having individuals who are highly experienced and skilled has a major impact (Jeni Tennison, Uche O., Michael Kay) </li></ul><ul><li>Synchronicity with XSLT UK 2001 </li></ul>
    16. 16. EXSLT informed XSLT 2.0 <ul><li>Working with RTF </li></ul><ul><li>XSLT is not a programming language </li></ul><ul><li>Abstracted complex XSLT (grouping) </li></ul><ul><li>Multiple Documents </li></ul><ul><li>String Handling </li></ul><ul><li>Evaluating XPATH? </li></ul>
    17. 17. EXSLT informed XSLT 2.0 <ul><li>Working with Result Tree Fragments </li></ul><ul><li>XSLT is not a programming language </li></ul><ul><li>Abstracted complex XSLT </li></ul><ul><li>Outputting Multiple Documents </li></ul><ul><li>String Handling </li></ul><ul><li>Evaluating XPATH ??? </li></ul>
    18. 18. Benefits to XSLT 2.0 <ul><li>Allowed XSLT 2.0 to take a bit longer </li></ul><ul><li>Provided W3C Working Group with real world evidence (e.g. XSLT 2.0 functions are not 1st class) </li></ul><ul><li>XSLT 2.0 and the suite of linked specifications puts EXSLT as we know it ‘out of business’ </li></ul>
    19. 19. EXSLT Future <ul><li>EXSLT as a specification has done its job and should die a ‘natural death’ </li></ul><ul><li>XSLT 1.0 usage will peak, which is why I have submitted a complete build based on Ant which generates site document, platform specific module imports, and reports on XSLT processor compatibility; up to the rest of the EXSLT gang to review </li></ul><ul><li>Possible XSLT 2.0 function library? </li></ul><ul><li>Does EXSLT have application beyond XSLT ? </li></ul>
    20. 20. Facilitation <ul><li>EXSLT came from the whole XSLT community </li></ul><ul><li>EXSLT was a ‘bridge’ between groups like the W3C and the community </li></ul><ul><li>EXSLT goals were constrained and focused on what was important rather then ‘completeness’ </li></ul><ul><li>Why are there not more of these style efforts bridging the ‘problem gap’ e.g. etc.. </li></ul>
    21. 21. Open Source Specification <ul><li>Micah Dubinko recent open letter to WHATWG illustrates the point </li></ul><ul><li>Are there tools that can help us (developers)? </li></ul><ul><li>working on schema enabled wiki with annotation </li></ul>
    22. 22. Conclusion <ul><li>Suggestions…use cases, informal spec review, early implementation </li></ul><ul><li>Linking in XML, XML Schema, Xform, WS*, Binary XML, What to do with XML Namespaces…. </li></ul><ul><li>Thank you </li></ul>