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.
Related
We are planning to use Saxonica EE (yet to buy) in Spring Boot microservice on Cloud Foundry and we want to store the XSLT compiled version in XML in Redis cache so that when do transformation it would be less time consuming, I have below questions, can you please guide me in right direction.
how can we deploy Saxon EE libs with licence to the cloud, any standard practice need to be followed.
is it possible to get the XSLT compiled code in XML format so that I can store in Redis cache, is this approach make sense (if there is any change in XSLT I will re-compile every time)
Any java programming samples, we use xsl:include heavily in all xsls , if there is any example for the same use-case would be great.
For the commercial questions regarding licensing for cloud deployment, that's out of scope for StackOverflow - please contact Saxonica directly to discuss this.
Saxon-EE can compile a stylesheet to a SEF file which is indeed an XML format, but I've no idea whether storing the compiled stylesheets in Redis makes any sense.
If you have a problem using xsl:include, I suggest you raise it as a separate question. A general request for advice on using a particular feature isn't likely to elicit helpful responses - StackOverflow works best if you have a specific technical question, or a specific technical problem. (If you want general advice, my XSLT reference book has about 4 pages on xsl:include, with examples).
I recommend you to start by getting the basic foundation of clarity in place as described below:
About choosing Redis for storage :
If your going for Redis as storage you normally would have to serialize your (XSLT processed) output into XML or JSON prior to storing it into Redis. This means also that any time you want to access the data in a more human-friendly readable way, you would have to deserialize the Redis string.
Answers on your bulleted questions (in relation to XSLT) :
[1] Cloud deployment: Even if you would like to use cloud solutions you would still need to define on which server you would like to install Java/SDK and Saxon libraries (jar). In terms of details around license for cloud solution, I would refer to the company Saxonica.
[2] Need of compiling: Saxon XSLT is not normally being compiled by user (unless there is a reason for it). I suspect when you say "compiled" in this bullet that you mean the transformation process, using a source XML, XSLT for processing and getting an output XML. - If so, you can set which output format you want (XML/HTML/XHTML). Every time you change something in your source- or XSL file, you would need to run XSLT to see the change in the XML output file.
[3] Need of Java samples: You do not need Java knowledge to build XSL stylesheet files. The Java comes into the picture if you choose to run on Java you would need to setup Java/SDK on the machine that would run Saxon XSLT. After the setup (Java/SDK and XSLT) you can choose between calling XSLT from a terminal or create scripts that would call XSLT (I use bash scripts in Linux).
I recommend that you start using an online XSLT tool meanwhile you solve your Java environment and Saxon XSLT. This way you can build up your XSL files or test any of your existing XSL files in order to adjust them to your needs.
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.
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'm in the market for an XSLT profiler.
I'm using the Xalan-j XSLT processor from Apache.
I'd like to be able to run the profiler under Windows or Linux as we have different teams using the same XML and XSLT on different platforms.
The tool needs to be able to work with exslt extensions.
The tool needs to be able to work with large (MB) input XML documents.
I'm not entirely adverse to paying for the right tool, but free (as in beer) would be nice.
I'm interested in hearing from people who have successfully used the tool that they recommend.
EDIT: updated, yes, xalan-j
I'm assuming you're talking about Xalan/J; I'm not aware of the options for Xalan/C++.
Stylus Studio had one in older versions, but it was dropped for Xalan in the current release.
The only other commercial one for Xalan that I am aware of that is any good is from Oxygen.
Note that sometimes switching on the profiler switches the XSLT engine into a debugging mode so that certain optimizations are not performed, so the profiler results should be taken with some common sense.
On-line XSLT processor based on xalan-2.7.1 with profiler information: http://xslt-profiler.appspot.com/
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.