As far as I know, SharePoint 2013 only supports XSLT 1.0.
What will be the destiny of XSLT in SharePoint 2016? IS it possible to deprecate XSLT? If the answer is yes, what is the alternative solution for server-side rendering?
I agree with Michael Kay that we shouldn't try to predict the future here, but if we rephrase your question to how you can use XSLT 2.0 with SharePoint, I think the question is valid enough ;).
That said, there apparently have been third parties that make XSLT 2.0 available from SharePoint. How that works exactly, I do not know, but this tool or toolset seems to offer you the possibility of XSLT 2.0 in Sharepoint and comes with a handy suggestion to update Visual Studio to make development easier.
Whether or not you can, or want to use Corasworks to get XSLT 2.0 working is a judgement I cannot make, of course. If you can somehow just use a native .NET XSLT 2.0 (or 3.0) processor, as far as I know, you can choose from XmlPrime, Saxonica and Exselt (disclaimer, I wrote the latter, and it is still in development).
Side note: Microsoft first claimed it would support XSLT 2.0 at some point, but stated later that it would not do so in the near future, and yet later that it would probably never do so and leave it to others to implement XSLT 2.0 in .NET. This logically leads to the same response on SharePoint and XSLT 2.0, but they are somewhere on the internet.
Related
I have a question regarding WSO2, Enterprise Service Bus, version 5.0.0, on MS Windows 7.
Can I replace bundled old Saxon 9.4.0.4 with the latest 9.7.0.11 (to get support of XSLT 3.0 and XPath 3.1 for XML transformation)? The bundled Saxon is in ".\wso2esb-5.0.0.zip\wso2esb-5.0.0\lib\endorsed\saxon9he.jar". It is Saxon, Java version, Home Edition, version 9.4.0.4, if I am right. When I replace it with the latest Saxon, HE, 9.7.0.11, I get many Java Exceptions.
So, is it possible, recommended, supported... to replace bundled old Saxon with the new one and/or even with licensed PE or EE 9.7.n.n?
Thank You in advance, Stepan
In general when an application bundles a specific version of Saxon there is no way of telling whether you can substitute a different version of Saxon except by (a) consulting the documentation of the application (if you're lucky) or (b) trying it to see if it works.
If the application sticks to the most stable APIs in Saxon then it will probably work, but if it dives down deeper to achieve closer integration then it may well make itself dependent on something that changes between Saxon releases.
That could be the case here. It's not entirely clear, but the error message
failed to create an XPathFactory for the default object model: http://java.sun.com/jaxp/xpath/dom
could suggest that the application is attempting to instantiate the Saxon XPath engine using the JAXP search mechanism, which we withdrew in Saxon 9.6 for reasons explained here:
https://saxonica.plan.io/issues/1944
I am trying to use Saxon to programmatically generate an XSLT. This is a similar question to Create xslt files programmatically, but as there was no acceptable answer to that question I am asking again, specifically around Saxon which at one point claimed to support this.
According to http://saxon.sourceforge.net/saxon7.0/api-guide.html, "This document describes how to use Saxon as a Java class library, without making any use of XSLT stylesheets."
(answering the other question I referred to above) and then serialize that to a stylesheet that could then be reloaded and executed later, but I already pretty much figured out that isn't going to happen.
If Saxon isn't the answer, what Java library will support any of this?
By the way, doing any and all of this using .Net is trivial. Unfortunately I need a Java solution for this.
Any help is greatly appreciated.
Well, for a start, there have been 26 major releases and innumerable maintenance releases of Saxon since release 7.0, so forget anything you read there.
It's not clear from your question whether you want to write your XSLT code generator in Java or in XSLT. I can't see why you would want to do it in Java rather than XSLT, but neither is difficult. The main problem with your question is that you don't explain why you think it's a problem. Generating an XSLT stylesheet is just like generating any other XML document: what's the problem?
I figured this out a while ago, and thought I would share my answer. This may or may be an answer for Create xslt files programmatically as well, but since that was not my question, I won't assume that.
The answer is not to use XSLT (or Saxon) at all. Originally I wanted an API with which to generate an XSLT model where the rules for transforming a particular (xml) tree structure are known programmatically. Then the model could be persisted as a style sheet so that it could be reloaded and used to transform another tree with the same structure again. Sure I could programmatically create a DOM containing an XSLT style sheet document, but why would I want to? It's inefficient for one - creating and saving a DOM with all the XSLT syntax (tedious), and then reading it using SAXON, etc. I'd rather have an API that natively understands XSLT - maybe one that has an XSLT model that can just be programmed and then serialized?
Anyway, the answer to my problem is just to use SAX. Since I know the particular transformation rules for my tree programmatically, I simply created a handler that processes the stream using the rules, and I'm done. In the end there's no XSLT style sheet that can live outside the program, but I'll live with that.
And I take back what I said about .Net supporting my first approach. I thought it would so it's just a reminder to check your assumptions before you post.
By the way, an answer to my question suggested that it was easy to accomplish but rather than outline how to do it, I was just questioned why I would want to. Can we at least try to answer a question if we also feel we need to ask someone why they are asking a question?
I found a post, please see the IBM formum post, where it says creating pre-compiled java classes (Translets) using Apache Xalan utility transforms XML files faster than just using XSLT.
I have been XSLT 2.0 but it is not working because Xalan only supports XSLT 1.0. The Saxon processor supports XSLT 2.0 but there is no utility to generate Translets.
Any suggestions?
The version of Xalan that compiles to bytecode translets is generally referred to as XSLTC. We did some recent performance measurements of Saxon-EE performance against XSLTC, which we reported at XML London 2014 (our paper is available at http://www.saxonica.com/papers/xmllondon-2014mhk.pdf) and the measurements we made are on Github at https://github.com/Saxonica/XT-Speedo. For the collection of tests we ran, Saxon-EE came out ahead by a whisker: as a crude summary, XSLTC ran a little faster on most tests, and Saxon-EE ran a lot faster on a few tests, so the results you get will depend very much on your workload. But the differences are a few percentage points, so it's very unlikely to really affect your ability to meet your project requirements. The productivity benefits of XSLT 2.0 over XSLT 1.0 are much more important for most projects than a 5% performance difference.
I think the Enterprise edition of Saxon 9.5 provides compilation to byte code, see the feature matrix http://www.saxonica.com/feature-matrix.html which says about that feature: "Available for both Java and .NET platforms, typically giving a 25% performance boost.".
As for IBM, it also has an XSLT 2.0 implementation available as part of Websphere, see http://www-03.ibm.com/software/products/en/xmlfp/, but I don't know whether it provides compilation of XSLT to Java classes or to Java byte code.
I'm in a bit of a weird spot. Due to events too ridiculous to list here, I'm working with a system that uses an unknown XSL engine. I'm fairly certain it's MSXML. The problem is that I'm not entirely sure which version (this is important). The original devs aren't available, and I have very limited access to the back end. What I do have the ability to do is author content (that gets fed through the XSLT sheets) and to edit the XSLT itself. Given these two abilities, is there any way I can make the parser report its version? Anything like PHP's phpversion()? Maybe even a standard way to report the XSL engine vender and version?
I'd be very willing to write a feature check sheet, if I could just find a list of XSL engines, and features unique to each.
You can process this XSLT stylesheet with your XSLT processor, it outputs some system properties, including the Microsoft msxsl:version.
<xsl:value-of select="system-property('xsl:vendor')"/> will tell you if it is Microsoft, but there is no property in XSLT 1.0 to tell you the version, only in XSLT 2.0.
I'm looking for an XSL lint tool which is actively maintained. The only one I can find is this one, but the last update was in 2000 (9 years old!). Any help would be great!
Phillip,
Creating a good lint for xlst is quite hard, because validity of xslt templates depends on the parser that is used. Each parser has it own extensions.
For example java's xalan can be easily extended with custom xpath functions, which are obviously coded in java. Because of that any .net validator will fail to validate advance xalan's xslts.
So first of all you need to know what processor you are going to use. If you use java based processors I recommend to use Eclipse which can validate the templates on the fly.
I've tired two eclipse plugins, It is worth mentioning that both support debugging and xslt/xpath code completion:
Oxygen XML editor - a commercial (~$300) XML/XSLT editor/eclipse plugin.
It can use the following engines: Xalan, Saxon, Xsltproc,
It is able to check:
correctness of xsl:template
correctness of name attribute of xsl:call-template
duplicated definition of xslt variables
validity of dtd's
validity of xslt header
validity of xml namespaces
validity of XPath
validity of xsl:value-of if an xml is associated to xslt
correctness of xsl:import for local and remote files (it support xml catalogs)
I must say that the plugin is really good but on the other hand it isn't open source.
XSLT Project - an open source plugin (it is part of Eclipse Web Tools Platform).
It is quite young (started in September 2008), however it has very active community. Currently it supports only Xalan and JAXP.
It detects the following errors and warnings:
invalid xslt header
incorrect dtd
incorrect imports (it handle only relative imports, xml catalogs are planed for version
1.1)
The above list is definitely incomplete because lack of support for xml catalogs made this project unusable for me.
Yes, look at this one, published Dec. 2008:
http://lists.xml.org/archives/xml-dev/200812/msg00178.html
You should look for "XSL profiler" or "XSL debugger". There are dozens of these.