The World Wide Web Consortium W3C has just published eight specifications as candidate recommendations for new XML transformation and query features. These recomendations represent a major change in XSLT, XQuery, and XPath. The message from the W3C is that these recommendations are now ready for implementation.

Liam Quin is quoted as saying that these specifications bring a new level of maturity to XML. These changes in the specification come after much consultation with people that are working with large collections of documents, traders, news feeds. These specifications are said to have considered the needs or both individuals and enterprise users.

All of the documents can be found at the following links.

• XSLT and XQuery:
  • XSL Transformations (XSLT) Version 2.0
  • XSLT 2.0 and XQuery 1.0 Serialization
  • XML Syntax for XQuery 1.0 (XQueryX)
• XQuery and XPath:
  • XQuery 1.0: An XML Query Language
  • XML Path Language (XPath) 2.0
  • XQuery 1.0 and XPath 2.0 Data Model (XDM)
  • XQuery 1.0 and XPath 2.0 Functions and Operators
  • XQuery 1.0 and XPath 2.0 Formal Semantics

XSLT 2.0 will only maintain backwards compatibility by the setting of an xsl:version attribute. This will cause the some 2.0 attributes to behave as they did in the 1.0. Other changes include stricter serialization rules, facilities for the grouping of nodes, transformations that can produce multiple result trees, regular express text processing, a XHTML output function, an enhanced data model with a type system based on sequenced of nodes or atomic values as well as many others.

Is the addition of strong typing to XSLT really a move in the right direction?

ok it is not in mustang, may be in dolphin(2009)
xalan(xslt) is not considering upgrading to the new spec
xindice(xmldb) seems to be frozen with no xquery(only xpath)
so... is it just specs for the java community
why we become so so slow in adapting new technologies?....

Saxon supports XSL 2.0 of course.
I did not know that Xalan has no plans for moving towards XSL 2.0. Why is that?

You are not forced to use Apache implementations like Xalan or Xindice. Use Saxon 8 for excellent XSLT 2.0 (and 1.0) support. Saxon is implemented by the "god" of XSLT, Michael Kay, who is also the editor of the XSLT 2.0 specification. For XML databases, consider eXist, which is way more advanced than Xindice. Unless I am mistaken, Xindice is pretty much a dead (or sleeping) project at the moment. We have bundled both Saxon and eXist in Orbeon PresentationServer (OPS) for a very long time, and would no longer touch Xalan with a 10-foot pole ;-)

Use Saxon 8 for excellent XSLT 2.0 (and 1.0) support. Saxon is implemented by the "god" of XSLT, Michael Kay, who is also the editor of the XSLT 2.0 specification.

Too bad, the "god" features are only in the commercial version of Saxon.

Use Saxon 8 for excellent XSLT 2.0 (and 1.0) support. Saxon is implemented by the "god" of XSLT, Michael Kay, who is also the editor of the XSLT 2.0 specification.

Too bad, the "god" features are only in the commercial version of Saxon.

This is a little misleading: only schema-awareness (and possibly some performance optimizations) are extra in the commercial version of Saxon. The open source version supports everything else in XSLT 2.0 and XPath 2.0, including typing with simple types. You should also know that XSLT 2.0 has two levels of compliance: "basic" and "schema-aware". The open source version conforms to XSLT 2.0 basic.

Use Saxon 8 for excellent XSLT 2.0 (and 1.0) support. Saxon is implemented by the "god" of XSLT, Michael Kay, who is also the editor of the XSLT 2.0 specification.

Too bad, the "god" features are only in the commercial version of Saxon.

This is a little misleading: only schema-awareness (and possibly some performance optimizations) are extra in the commercial version of Saxon. The open source version supports everything else in XSLT 2.0 and XPath 2.0, including typing with simple types. You should also know that XSLT 2.0 has two levels of compliance: "basic" and "schema-aware". The open source version conforms to XSLT 2.0 basic.

I was referring more to the performance optimizations that are included into the commercial version but not in the free one.

Are there any executive summaries available on what XSLT 2.0 and friends offer which XSLT 1.0 could not offer?

The only major problems with XSLT 1.0 are in my opinion (1) the lack of a standard way to determine whether a file exists; (2) the lack of support for generating multiple files and (3) lack of support for regex matching and replacements.

Finally I wonder whether XInclude functionality should not be included in XSLT.

I have been using XSLT here and there, on an occasion.

XML is used more than ever before, but what happened with XSLT? There was a big buzz about it around 2000-2002 but since then you hardly find a book written about it or article highligting it.

It was supposed to change web publishing, for example. People remember Cocoon, but who's actually using it? Did XSLT fall short? Was it too difficult? Or, did VHS win Betamax in form of PHP, JSP, ASP, ASPX over XSLT?

I find it useful for simple tranformations her and there, but as far as building big websites with it (and XML) did not cross my mind, though I knew about Cocoon etc.

Cocoon is more than just XSLT, it's a complete framework that offers all kinds of filters and transformations, not just XSLT-based.

XSLT is relatively slow, but still I believe it's used a lot. But it's typically used solely under the hood, so you may not notice it as much as you may notice an extension such as .jsp or .php.

Two examples of how we use XSLT, at the ISP I'm working for:

- in our dynamic front-end applications, both the ones for the customers and the ones for helpdesk agents; we've built a custom caching mechanism here, to speed up XSLT loading, especially for document() calls;

- in XINS, an RPC framework we've open-sourced at http://xins.sourceforge.net ; XINS generates client-side code, server-side code, HTML documentation, testforms, all using XSLT.

So XSLT definitely has its value and is used in practice. But you have to keep the performance-characteristics in mind. On our front-end servers we did some analysis once and we found that 2/3rd of the processing time was spent on XSLT processing.

If you have not applied XSLT in any project yet, just do it once. It is probably a steep learning curve, but then at least you have it in your repertoire. XSLT is a solution to specific problems, not to all problems.

I have been using XSLT here and there, on an occasion. XML is used more than ever before, but what happened with XSLT? There was a big buzz about it around 2000-2002 but since then you hardly find a book written about it or article highligting it.It was supposed to change web publishing, for example. People remember Cocoon, but who's actually using it? Did XSLT fall short? Was it too difficult?

Yes, it is too difficult to enter the mainstream - like any other functional programming language in the last 30 or so years.

I have been using XSLT here and there, on an occasion. XML is used more than ever before, but what happened with XSLT? There was a big buzz about it around 2000-2002 but since then you hardly find a book written about it or article highligting it.It was supposed to change web publishing, for example. People remember Cocoon, but who's actually using it? Did XSLT fall short? Was it too difficult?

Yes, it is too difficult to enter the mainstream - like any other functional programming language in the last 30 or so years.

I write application using many different langauges, and have standardized on XSLT for my presentation logic. I did find the up front learning curve a little harder then JSP and ASP, but not that much so. I am always surprised when people bitch about how hard XSLT is. Really I don't get it. Once you have learned XSLT it applies to any langauge, you can also more easily write cross langauge presentation level interfaces. You can also have an XSLT based presentation level interface that can produce HTML, or XML for Flash or Ajax without changing your programing model or learning anything new on the server side.

Personally I think that from a maintainability point of view that XSLT is a far step above JSP or ASPX. XSLT based systems truly allow content developers to focus on content, and application developers to focus on the core application. I prefer a simple XSLServlet type approach as it can be more easily integrated into popular existing MVC frameworks.

I have found in projects that I have worked on that you can train and HTML developer to get up to speed on XSLT much faster then teaching them enough Java to understand how to work on most JSP applications. In theory JSP should allow you to seporate your presentation and content just as XSLT does, but in reality this rarely happens. Most all JSP based applications contain JSPs that are littered with Java code in <% %> tags. XSLT forces seporation, and in the long run, in my opinion leads to cleaner presentation code.

Another benefit with using an XSLServlet type of environment is that you can work on the xsl files without having to republish the application, making presentation level development less time consuming.

The main downfall that I see with XSL based solutions is performance. There are things you can do to speed up XSLT, but not matter what I have tried the it seems to stay a step behind JSP's. (Mind you I have only seen the effects of this when load testing an xslt based application with 100s of concurrent requests).

XML is used more than ever before, but what happened with XSLT? There was a big buzz about it around 2000-2002 but since then you hardly find a book written about it or article highligting it.

I use XSLT a lot. One example of how it is useful is for transformation of various XML formats to XSL:FO for report generation. Checking on DICE there are over 1700 jobs which list XSLT or XSL as a requirement. That is about more than the number requesting Struts, so shows that XSLT is pretty widely used.

XML is used more than ever before, but what happened with XSLT?

XSLT has three great fundamental problems.

The first is that it isn't WYSIWIG. Unlike JSP or Velocity, an XSLT stylesheet isn't a document template. Instead an XSLT stylesheet is a jumbled bunch of fragment templates. I say 'jumbled' since XSLT imposes no declaration ordering on the fragment templates. The templates in an XSLT stylesheet could be reordered arbitrarily without breaking the stylesheet. Contrast that with JSP or Velocity, where the templatized content must appear in the same order as the result document, and this constraint is what achieves WYSIWIG. A lot of XSLT's complexity went into accomodating source documents for a recursive schema (eg, an XHTML page can have <table>s nested within <table>s arbitrarily deep. This capability is mostly a waste since most enterprise documents don't have a recursive schema. XSLT is largely an anachronism. It's sweetspot existed prior to modern templating dialects and before ubiquitous facilities wrapping DOM and XPath, such as JAXP. It was only a few years ago that JAXP didn't ship with the JRE, and even more recently that whatever implementation of JAXP did come in the JRE was so bad that it typically had to be replaced with an endorsed upgrade to serve any worthy purpose.

The second problem with XSLT is that it's yet another alien processing language. It's a functional programming language, when most enterprise monkeys have already settled on some general purpose OO language that they love. These languages now have excellent integration with XPath, thereby stealing much of XSLT's value.

The third problem is maximum development productivity expects a decent XSLT IDE, which is presently an oddity. Most code monkeys have yet to realize that XML is an excellent processing syntax.

Do you really need WYSIWYG for web applications ? I don't think so. I have bet (and won) against any smart guy who thought he could be quicker with a WYSIWYG HTML/JSP/ASP editor than me with UltraEdit (a very good text editor) and a good image editor. And if you really need it, having worked with XSLT for 6 years, I don't see why template ordering should prevent WYSIWYG. And then again, I don't need an IDE, just UltraEdit. Don't bet against me on this ; you'll lose.

Here are the reasons why XSLT is such a great tool to make web applications :

- programming platform independance ; you can use the exact same presentation code with ASP, PHP, J2EE, .NET, etc. And that's a big advantage, especially for a small company like mine that can't tell its big customers : "it's .NET/PHP/J2EE (take your pick) or nothing !"

- you can output anything with XSLT (FO->PDF, CSV, XML, HTML, XHTML, etc.)

- it forces you to use the right paradigm (data manipulation in the data layer, data presentation in the presentation layer) because you can't make data manipulation in XSLT. I haven't seen an ASP.NET/ASP/J2EE project (without even mentioning PHP...) where presentation and business are not at least a little mixed in what is supposed to be the presentation layer (and vice versa). I've been separating layers cleanly before JSP even existed, and I feel really good about it...

- the brand new technique in ASP.NET 2.0, master pages, which enables you to use the same surroundings (menu, etc.) for all your pages, has been possible with XSLT since the very first version.

And who cares if the right technology for a specific problem is not OO ? If I have a programming problem, and if the right tool for it is not OO (or even contains a "goto" statement :)), I don't care, I use it. And for me, with all of XSLT advantages, the lack of OO orientation is not a concern at all.

And when you say that the fact that languages have integrated XPath librarys, thus stealing much of XSLT's value, it definitely shows that you didn't get what is XSLT's value (see above).

I don't know if I will convince you (or anyone for that matter), but after all, I prefer being almost the only one using the most productive technology :)

Peace

François Lemaire

I don't know if I will convince you (or anyone for that matter), but after all, I prefer being almost the only one using the most productive technology :)

That's the point! If you are the only one who can use the tool than you simply produce unmaintainable code (unmaintainable for others). XSLT has many indisputable advantages and it is great in theory. But it is not a simple and convenient tool in practice. 'KISS' is the most important feature of a tool.

XSLT has many indisputable advantages and it is great in theory. But it is not a simple and convenient tool in practice. 'KISS' is the most important feature of a tool.

What is so hard about XSLT?

What is so hard about XSLT?

Let me first say that I like XSLT. It can be very productive when used frequently (it takes some time getting into this thinking). The two things I find hard about it are:

Namespaces: Source and target documents that use an overlapping but not quite identical set of namespaces. Differing default namespaces. Namspace translations, that is, modifying namespace URIs (something that probably shouldn't happen but still does). And a few nasty special cases that I don't want to get into here.

Visual confusion: This one may be down to my own visual deficiency, but I find it hard to tell things apart in this soup of angle brackets where the source document, the transformation instructions and the target document use very similar syntax.

Still, it's amazing how concise some transformations can be expressed in XSLT. XSLT 2.0 has some very nice additions like the grouping features and XSLT functions. XSLT really is an investment. I doesn't come easily but if you master it, it's a big asset.

Namespaces: Source and target documents that use an overlapping but not quite identical set of namespaces. Differing default namespaces. Namspace translations, that is, modifying namespace URIs (something that probably shouldn't happen but still does). And a few nasty special cases that I don't want to get into here.

I do agree with you here. There are a set of namespace issues that can kind of make life hell.

soup of angle brackets

ha ha ha I like this quote ;) Yes there are times that XSLT can look more quite messy. Mostly if you are creating elements from scratch, which many times is nessary.

I still prefer this type of mess to the type of mess that occures when people start doing a lot of <% %>, especialy if they start using scriptlets for conditional logic.

If KISS is the most important feature of a tool, then XSLT is the best tool to make web sites. Do you have a simple way of displaying the data transferred from the data layer to the presentation with Servlet/JSP or ASP/COM or ASP.NET ? No, you don't. With XSLT, you just type this :

<xsl:template match="*" mode="copy">
<<xsl:value-of select="name(.)"/>&#160;<xsl:apply-templates select="@*" mode="copy"/>>

<xsl:apply-templates select="*|text()" mode="copy"/>

</<xsl:value-of select="name(.)"/>><br/>
</xsl:template>

<xsl:template match="text()" mode="copy">
<xsl:value-of select="."/>
</xsl:template>

<xsl:template match="@*" mode="copy">
<xsl:value-of select="name(.)"/>="<xsl:value-of select="."/>"&#160;
</xsl:template>

This set of template writes the whole transformed XML document into the HTML output, thus you know very quickly what the data you're supposed to display looks like. And that's just an example in many, many ones. Isn't it easier to maintain too ? Easier than scores of Vector containing God knows what type of Java objects ? Isn't it more readable than JSP tags too ? Most of the time, JSP <% %> tags break the flow of HTML, and make it difficult to read (especially loops and tests). Two more things :

- XSLT is a standard, and in my long experience as a developer, one of the best implemented in the industry. The standard set of xslt tags and XPath expressions work EXACTLY the same on all platforms.

- XSLT is very easy to learn ; when we hire a new developer to work with our toolset, he's productive in 2 or 3 days at most, and never did anyone of them tell us that it was hard to learn.

I think one of the problems was that people lost the plot with Xml and started Xmlising everything, mainly because it was very easy.

The shock was when people expected everything in the Xml world to be as easy. Xslt is nowhere as easy as Xml, but it's not that difficult either - i think it was the step required between the two that became a big problem (certainly for those people learning Xml that i knew). Very simple to use a procedural language, load some Xml and fire in some simple XPath (of which i have even seen hideous uses) - but Xslt was a new way of thinking *on top of understanding Xml*. In the race to actually be able to DO something with it, procedural was always going to win (as no-one had to learn more than a few classes).

I use Xslt most days and am in battle with many who hate it - yep, hate is applied to Xslt more than anything else i know. What i actually think most people don't get is XPath. I can tell that just by looking at how is it used in procedural code ("//element" is v. common).

I will use it for data transforms, reports, content display and so on. It's more difficult to use it on interactive forms - but it's great for outputting multi-language controls and so on. I'm afraid to say that Xslt, XPath and XQuery are not worlds apart (XPath being the common denominator) and i suspect that once people get their heads around one, the rest will be simple.

ReportLab, Inc., for example, is an enterprise vendor that delivers products and services having to do with high-quality report generation to some of the largest organizations in the world, including Fidelity Investments and American Insurance Group.

ReportLab founder Andy Robinson explained that his development team has deep experience in projects that transform XML. Each project his company has fulfilled has involved coding in a lighter-weight scripting language rather than relying on XSLT. Even though XSLT is specialized for XML transformation, his consulting teams have found it easier to use Python as a more general-purpose, but powerful language.

The reason why I started asking if XSLT is having difficulties because of reasons mentioned above. Some people do seem to find it easier to deal with XML with other tools. The point about xpath support in other tools can be compelling. For example, look at one of the Velocity sub projects:

DVSL : Declarative XML Transformation and Templating

It claims to take all the good things about xslt such as xpath and the declarative syntax, but the rest is velocity scripting. Take a look at examples:

http://jakarta.apache.org/velocity/dvsl/users-guide.html#Getting%20Started%20:%20Building%20and%20Using

Stylus Studio's XSLT editor and XSLT debugger supports the new W3C XSLT 2.0 and XPath 2.0 standards.