If you are using XSLT and you think that XSLT 2.0 would provide you some real benefits, please drop a line of comment with a short explanation pleeeease. I'm collecting some arguments for XSLT 2.0, some real world scenarios that are hard with XSLT 1.0, some business cases when XSLT 2.0 would provide an additional value. That's really important if we want to have more than a single XSLT 2.0 implementation...
PS. Of course I've read Kurt's "The Business Case for XSLT 2.0 " already.
Update: I failed to stress it enough that it's not me who needs such kind of arguments. We have sort of unique chance to persuade one of software giants (guess which one) to support XSLT 2.0 now.
When it comes to
business email many growing companies need to keep in mind that their business email
services are a huge part of the communication in the business, and the right business email
can help to run a tight ship.
If Microsoft embraces XSLT 2.0 and XPath 2.0, I assume we will see this manifested not just in System.Xml etc, but also in products like SQL Server. Sadly, SQL Server 2005 still seems behind the XML & XSLT capabilities Oracle rolled out as an add on to Oracle 8i in 2000. Compounding that, in January 2005 Oracle 10g was already supporting major portions, if not the entire kit and kaboodle, of these specifications.
So, in terms of sheer competitiveness in the X-space, Microsoft is behind.
As for my needs, strongly typed stylesheets should substantially increase performance. And features such as grouping provided specific permormance benefits to transformations common in many XSLT applications.
This is not to take away from the schema-awareness to extend significantly the ability of XSLT in general to process XSD typed XML in ways which will benefit projects.
The conformance with IEEE standards for floating point numbers & operations provides meaningful functionality to anyone wanting to do math, whether accounting, scientific calculations etc. There's a substantial amount of work of this type I forsee in my immediate future.
Response to Julian:
Excellent advice. In fact this is something that is being worked on as we speak. While support for all of XSLT 2.0 is not necessary (e.g. multiple output), it certainly doesn't hurt.
I'll keep things updated here > http://weblog.saxondotnet.org
I don't have an opinion about XSLT 2.0, but I'm half way through Michael Kay's XPath 2.0 and like what I see. I'd like Microsoft to move forward with XSLT 2.0 so I can get XPath 2.0!
Well, I really do not care a lot whether Microsoft supports XSLT in their
.NET framework. Nobody stops developers from using a non-MS solution there.
What I *do* care about is XSLT support in the browser. Remember? "XML on the
web" they told us. So yes, it would be great if IE7 would support XSLT2.
That may even be a business case, because Firefox doesn't, and it doesn't
look as if this would change anytime soon.
I recently wrote an XSL transform that converts XHTML 1.0 Strict to HTML 4.01 Strict [http://j.porter.name/code/xhtml-1.0-strict-to-html-4.01-strict-xslt] (which only seems trivial). When I wanted to add support for <?xml-stylesheet?> processing instructions, despite its direct correlation to a HTML <LINK> element, I found it was virtually impossible to accurately & reliably convert from the procession instruction to the <LINK> element even with EXSLT. XSLT 2.0 provided me with all the tools necessary to do a near-perfect one-to-one transformation with any valid source XHTML 1.0 Strict document.
+1 from me too. The XSLT 2 is now in the candidate recommendation phase and a lot smaller companies like Altova already have a working implementation that support it. I can't imagine Microsoft not having enough resources to do this.
I understand that timing was not right for the .NET Framework 2.0 and Visual Studio 2005, but the immediate next version of either or both should carry the XSLT 2 implementation.
Instead of Microsoft asking us why, we should probably ask them - why not? Especially in the light of the post you link to (from Kurt Cagle).
For me the most annoying limitations of XSLT 1.0 are:
- it is impossible to output several results without using extension functions
- it is impossible to treat the result tree fragment type as the node set type without an extension function and thus it is impossible to perform double transformation within same XSLT stylesheet (to store transformation result in some variable as an intermediate result and then to apply other templates over the variable content to produce final result)
- very limited number of standard functions.
- there is no simple way to create loops with determined number of iterations. I know that I could use recursion or I can put a number of xml elements in the XSLT itself and iterate over them using document('.') function, but these solutions looks like hacks. XSLT 2.0 sequences could help a lot in such cases.
Good points, Andrew! Limitations of XSLT 1.0 force people to use extensions, which is no-no in some environments.
Scripting in XSLT is now disabled by default in both MSXML and .NET 2.0 so XSLT 2.0 can help users to avoid introducing unnecessary security vulnerabilities into their systems just to overcome another limitation of XSLT 1.0.
Mark, we'll go that way for sure if whoever-at-micsrosoft decides not to invest their scarce resources to implementing XSLT2.
I recently had to construct an XSLT to convert from a proprietary XML
grammar to an RDF application. There were two area that made this difficult
in XSLT 1.0.
The first area was, this XSLT needed to construct a URL and therefore needed
to hex escape various parts of the final URL. In XSLT 2.0, there is the
XPath 2.0 function encode-for-uri. While it is possible to duplicate this
functionality in XSLT 1.0 using scripting, the XSLT that was being developed
could not use scripting for security reasons.
The second area was, this XSLT was creating RDF. The RDF specification
requires that content be encoded as Unicode normal form C. The original XML
grammar used a pseudo-encoding of Unicode normal form D. In XSLT 2.0 there
is the XPath 2.0 function normalize-unicode which does this. In XSLT 1.0 it
would near impossible to do properly without scripting and even using
scripting I'm not aware of any script, e.g., EXSLT or otherwise, that would
take Unicode in any normalized form and produce Unicode normal form C.
Many thanks to the people on the XSLT 2.0 working group who saw the need to
include these two useful XPath functions.
A few prime areas for me.
1. Grouping. 100% answer to user needs.
2. Text munging. analyze-string and regex.
3. Tokenize. Again text munging.
4. Formalization of exslt toolkit, there by user demand.
XSLT 2.0 basically makes XML processing much
easier.
Hey Oleg, this is fantastic to se you jump on this. As a possible enhancement to this, the other day I finished setting up a server that is dedicated (partially anyway) to hosting SVN, darcs, bzr, and monotone-based repositories specifically for the use of the XSLT community to begin developing a centralized library of XSLT 1.0 and 2.0 transformation files that can easily be accessed via any of the above client-side tools. This will be a part of the XSLTransformations.com project so it seems it would obviously be an appropriate place for people to both check-in, browse, and check-out any and all use cases and their related code specific to this project.
Let me know if you think this would be both helpful and appropriate and I will get you set-up as an admin on that server.
I know I for one plan to contribute as much code as possible to your project, and plan to store it on this same mentioned server for others to access. So one way or another the server will begin to see access here in the not too distant future.
Cheers :)
Mark
Yes, please do!
My personal understanding, as opposed to official MS position, is that Microsoft *will* implement XSLT 2.0, the only question is when. The information that Oleg asks for would be very useful to those who want it to be as soon as possible. We have to make the business case to some hard-nosed people who get all sorts of other ideas about how to allocate scarce resources.