3 Comments

1. John C

   Posted on January 23, 2010 at 11:44 am

   XSLT lets you take full advantage of the XML format, for any form of XML. These days they are quite numerous and very popular: RSS, XHTML, DocBook, TEI, XSL-FO, XForms, RELAX NG, XML Schema, SVG, SMIL, RDF, OWL, and many more. Plus, you can define your own XML document type.

   XSLT can take any XML document, and translate it to HTML, another form of XML, or some other plain text document type like PDF.

   Because it can both take in and output data in XML format, XSLT lends itself very well for a trick called “pipelining” that is where you do a series of transformations, one after another.

   The output of one stage becomes the input of the next stage. It is a very powerful technique for decomposition of a large, complex solution – into modular, reusable components.

   XSLT can easily sort, filter, reorder/reorganize, and tweak data in XML format. XSLT 2.0 makes it easy to group data as well. For example, if you have a lot of records in random order that give sales per salesmen, per city, per region – XSLT 2.0 can sort them all for you, grouped in nested hierarchies by: region, then city, and last the sales total for each salesman in city.

   XSLT is pretty simple, as programming languages go. Unlike most popular programming languages, it directly supports XML. It has support for XPath expressions built right into it.

   XSLT can operate directly on dynamically generated XML data. Hand editing data that does not exist yet is not an option in this case!

   Many programming languages support editing XML data via an API called the DOM. The problem with the DOM is that it is cumbersome and verbose. You have to say a lot to get a little done. It is also not capable of doing the automatic sorting and grouping operations that XSLT done. Another flaw is that it has to read the whole XML infoset into memory. With big files, this makes the program run slowly – and can strain memory resources on the server or computer it is running on.

   By contrast, XSLT is event-driven. It operates sequentially on each node of data (element, content, comment, program instruction, whatever) as it comes in. That means XSLT runs very fast and it scales nicely for big files.

   Writing code to directly generate HTML is no fun at all, especially if you have not done it before. There are many rules you have to learn if you are doing it all yourself:

   1. Any use in content of the characters: < , >, ”
   - MUST be escaped, either by using character entities (those ampersand+word+semicolon things) or by using a !DATA construction.
   2. All elements must either be marked as empty like this or have an end tag corresponding to the start tag, like virtues tags in this example: .
   3. Namespace rules must be observed.

   XSLT is is well supported by both web/application servers – and web browsers (web clients). Right here, is a great example of how the power of pipelining can be harnessed.

   Canonical data transformations – aggregating data and getting it into a common format – as well as grabbing it all in the first place, and filtering out any completely unwanted data, can be done on a server.

   XSLT can be invoked statically and/or (using Javascript) dynamically on the client to do further transformations. The decision as to which side of the client/server divide to do these transformations on can be a tactical one made by the architect.

   XPath expressions, a natural way to refer to pieces of XML, is directly supported by XSLT. It can be used in logical expressions such as in “if’ constructions and “test” constructions, as well as template declarations.

   The basic tags you must learn to do pretty much any useful XSTL are:

   template
   apply-templates
   if

   It is also very helpful if you also learn how to use:

   test
   call-template

   If you have someone on your team who took LISP, Scheme, or any other functional programming (FP) languages in school or taught one to themselves – they will probably take to XSLT like a fish to water.

   Programmers who only know mainstream procedural languages like Java, Javascript, C++, C#, C, Pascal, or FORTRAN will be somewhat stymied by XSLT’s different way of doing things.

   However, if they have done a lot of event-driven programming – such as writing GUI code or computer protocols software – they might not find it too bad. XSLT template match constructions are basically pattern-match triggers for XML nodes.

   Programmers who have worked in a rule-based language, such as CLIPS, might also find the template match approach to programming encouraged by XSLT to be familiar. These are rule-based, so there is a parallel in how these things work.

   The web has clearly adopted XML in a big way. No one contests that. Not anymore. Just look at the long, varied list of XML document types at the start of this answer. A lot of data is in XML format these days. Much of it is constantly, frequently changing. XSLT fits very well into this environment.

   XML is not going away for a long time, nor will it change in drastic ways in the near future. XSLT will not be going away either.

   The first version has been supported in all major web browsers for years. Web browsers do not yet support 2.0 directly but probably will within a couple years. For now, the pre-2.0 standard is the universal one.

   AJAX programming frequently uses XSLT. Case in point: Gmail from Google.

   Apache has had a web application service out for over half a decade that is heavily organized to support XSLT: the Apache Cocoon project.

   XSLT support has been built-into Java since JDK 1.4, which came out almost half a decade ago. JDK 1.5 has been out a couple years, and JDK 1.6 will probably be out around the turn of this year. So support in Java for XSLT is well-established.

   I have used XSLT to program reporting systems, and it worked extremely well for that. I have also XSLT to automate generation of reliable, extremely user-friendly error-handling/reporting logic. These are just a few of the more sophisticated things that can be done with XSLT, beyond the obvious ones.

   W3-standardized XML format SVG (scaleable vector graphics) is now directly supported by the wildly popular, free web browser Firefox. Websites are already starting to use it in impressive ways and you can bet a lot more will in the future.

   So the effort required to learn XSLT will be paid back with dividends over many years. It has been a practical, widely used tool for several years. Now is the time to learn it, and this is the year to use it.

   I have provided links to the XSLT spec, as well as a number of links to resources to help learn to start using it right away.

   A couple words of caution: support for use of XML Schema and DTDs by XSLT scripts is limited at best, and tricky to incomplete at worst. Since some XML documents rely on defaults set in these files, this can lead to unexpected problems when processing these files with XSLT. Pay attention to how/if your XSLT processor can be told to use these, and to what extent it will.
2. run4ever79

   Posted on January 23, 2010 at 11:15 am

   As aditsu mentioned, it allows you to separate the content layer from the presentation layer. The to big advantages are that you can automate the generation of content by replacing the static file with a script (you can do this with html too), and you can support other file formats trivially. For example say your page is a report generated from a DB query. You can generate an XML format report using a basic webservice, and then your client code could present that result as an HTML table, a CSV file, or another XML format such as OpenDoc or the Microsoft Office 2003 format.
3. aditsu

   Posted on January 23, 2010 at 10:52 am

   The main advantage is the separation between content and presentation. With XSLT, you can have an XML with the raw contents of the page, and one ore more XSLT files specifying the presentation (which can have different designs, or even be targeted to different media). And you can modify them independently.