I am trying to modify an xsl which is of the older version. I come across the following:
<xsl:eval>FormatAccount(this)</xsl:eval>
<xsl:script>
function FormatAccount(e) {
// function details
}
</xsl:script>
I am trying to call the FormatAccount() javascript function using <xsl:eval> and the function is written in <xsl:script>.
How to do this as per the latest standards?
The latest standard is XSLT 2.0 http://www.w3.org/TR/xslt20/, it does not have any facility to define functions in Javascript, it however allows you to define functions with XSLT itself: http://www.w3.org/TR/xslt20/#stylesheet-functions.
XSLT 2.0 is supported by XSLT 2.0 processors like Saxon 9 http://saxon.sourceforge.net/, AltovaXML Tools http://www.altova.com/altovaxml.html or XQSharp http://www.xqsharp.com/xqsharp/beta.htm.
If you want to use Javascript to define extension functions we need to know which XSLT processor you use, of those three XSLT 2.0 processors I mentioned I think only AltovaXML Tools allows that (http://manual.altova.com/AltovaXML/altovaxmlcommunity/index.html?xextmsxsl.htm), and only, I think, to allow easier migration of XSLT 1.0 stylesheets written for Microsoft MSXML.
If you want to use an XSLT 1.0 processor then there too defining extension functions in a particular programming language like Javascript depends on the processor you use, for MSXML there is an msxsl:script element: http://msdn.microsoft.com/en-us/library/ms256042.aspx.
Embedded extension functions in other language is not the content model of XSLT.
Extension elements and extension functions are part of the content model as described in http://www.w3.org/TR/xslt#extension : it's implementation dependant how exactly an XSLT processor register those extensions.
As pointed by #Martin Honnen's answer, in XSLT 2.0 you can declare "stylesheet functions" with XSLT itself.
Related
As far as I understand, we can use 1 XSLT to read multiple xml files as inputs. May I know if there's a way to read multiple inputs and produce multiple outputs as well (within 1 XSLT)?
Yes, this is a standard feature of XSLT 2.0, with the xsl:result-document instruction.
Some XSLT 1.0 processors offer similar capabilities using vendor extensions, but it's not possible within the W3C standard.
I'm trying to use Saxon 9.1.0.8 HE to apply (recent) Docbook XSL, and getting this:
Don't know how to chunk with SAXON 9.1.0.8 from Saxonica
Processing terminated by xsl:message at line 46 in chunker.xsl
Docbook XSL source claims that:
<!-- This stylesheet works with XSLT implementations that support -->
<!-- exsl:document, saxon:output, or Xalan's redirect:write -->
<!-- Note: Only Saxon 6.4.2 or later is supported. -->
...and a visit to line 46 mentioned in the error message (which tests for element-available('saxon:output')), and to Saxon documentation, shows that the root of the problem is that Saxon no longer recognizes the saxon:output extension.
This source suggests that to make Saxon 9.4 compatible with XSLT 1.0 (which is what the stylesheets are in, and what saxon:output used to be good for in the first place), some kind of "backward compatible behavior" must be enabled. But why, and how?
(The docbook stylesheet in question does specify <xsl:stylesheet version="1.0" xmlns:saxon="http://icl.com/saxon">.)
I'm no expert in DocBook, but I believe the Docbook 1.0 stylesheets probably work best with Saxon 6.5.5, and if you want to use the latest Saxon releases (e.g. for performance) then you're probably better off using the Docbook 2.0 stylesheets: see
http://norman.walsh.name/2011/08/25/docbook-xslt-2
If you want to run XSLT 1.0 stylesheets trying to access extensions in the namespace xmlns:saxon="http://icl.com/saxon" then you should use the lastest version of Saxon 6 which is 6.5.5 I think.
Saxon 9 is an XSLT 2.0 processor and I don't think that comment talking about "Saxon 6.4.2 or later" has Saxon 9 in mind, it is solely talking about the Saxon 6.x releases of the XSLT 1.0 processor.
Other than that I agree with Ken, if you want to use Saxon 9 then edit the stylesheets to use the XSLT 2.0 xsl:result-document.
Saxon 9 supports XSLT 2.0, so just use <xsl:result-document> to create multiple result trees.
In a reply to a post I made the other day Dimitre pointed out, correctly of course, that I had given an XSLT 2 answer to an XSLT 1 question.
However, he also upbraided me for posting an answer that hadn't been tested. I had in fact tested it and even though the version attribute was set to "1.0" and I used an XSLT 2 replace function every worked with errors or warnings.
So this raised a question - what does the version attribute mean if it doesn't restrict the language to a particular version?
I did try reading the w3 spec but my eyes started to bleed.
FWIW: I use Oxygen and Saxon 9.3 EE
Firstly, the XSLT specification says how an XSLT processor interprets the version attribute, but it doesn't constrain what pieces of software other than an XSLT processor do with it. For example, an IDE (such as XML Spy) might look at the version attribute and use it to decide whether to launch an XSLT 1.0 or XSLT 2.0 processor. Once an XSLT 1.0 or 2.0 processor is launched, its behaviour is controlled by the relevant spec.
What an XSLT 1.0 processor does with the version attribute is defined by the XSLT 1.0 specification; what a 2.0 processor does is defined by the XSLT 2.0 spec.
The XSLT 1.0 spec says that if the version is NOT 1.0, the processor runs in forwards compatibility mode. This basically means that it does its best to ignore constructs that aren't defined in the 1.0 spec. So if your stylesheet says version="2.0", and you run it with a 1.0 processor, then an attribute that is new in 2.0 like xsl:sort/#collation will be ignored. An instruction that isn't recognized causes a failure only if it is actually executed, and if it has no xsl:fallback child instruction to give a fallback behaviour for 1.0 processors. The design principle is that using 2.0 constructs should not cause a 1.0 processor to fail; wherever possible, it should cause it to run with some kind of fallback behaviour.
The XSLT 2.0 specification (which controls the behaviour of a 2.0 processor) distinguishes verion<2.0, version=2.0, and version>2.0. When version<2.0, the processor runs in "backwards compatible mode". This doesn't mean that 2.0 constructs are rejected; rather it means that 1.0 constructs are executed with semantics as close as possible to those defined in the 1.0 specification. For example, all arithmetic is carried out as double floating point, even if the operands are decimals. When version>2.0, the processor runs in forwards compatible mode, which is very like forwards compatible mode in the 1.0 specification: it means that if you use XSLT 3.0 constructs, the processor will do its best to ignore them or execute fallback instructions.
I also use oXygen for both XSLT 1.0 and 2.0 development. If I try to use an XSLT 2.0 function in a stylesheet that has a version number of 1.0, oXygen will warn me.
Check your oXygen settings and make sure you're validating XSLT 1.0 with a 1.0 processor:
Notice I'm validating 1.0 with Xalan.
Also, I always test my 1.0 answers with a 1.0 processor; usually with both Saxon 6.5.5 and Xalan.
I am trying to execute the string contained in an XSL variable.
Umbraco has hooks for several Exslt pieces, but it seems the Exslt.dyn (Exslt.dynamic) is not one of them.
How do you add it in? Acceptable methods (in order of preference:
Writing your own XSLT extension (possibly using existing Umbraco code for Exslt Dynamic).
Uploading the XSL from http://www.exslt.org/dyn/functions/evaluate/index.html into Umbraco.
Modifying the Umbraco source to add it (possibly using existing Umbraco code for Exslt Dynamic).
The reason I mention Exslt Dyanmic is because some Umbraco XSLT sources show a reference that I am assuming existing in some versions of Umbraco. I cannot find it in the source code, however. (Example: the XSL sources pasted in here: http://our.umbraco.org/projects/starter-kits/business-website-starter-pack/general-%28bugs,-feedback,-feature-requests%29/8085-Changing-the-first-day-to-fx-monday)
Very few XSLT processors implement dyn:evaluate() and Umbraco obviously doesn't use one of these.
There isn't anything you can do in this case.
Ask the Umbraco developers to incorporate an XSLT 2.0 processor in the future -- XSLT 2.0 has a native <xsl:function> instruction for defining functions that can be referenced in any XPath expression.
Not sure if this will work, but if Exslt.ExsltDynamic is supported out of the box in the .Net implementation of XSLT, this should work. In your stylesheet add the namespace xmlns:Exslt.ExsltDynamic="urn:Exslt.ExsltDynamic" (as in the example you linked) and in the exclude-result-prefixes property add Exslt.ExsltDynamic to make it accessible in your xslt file.
Then you can just do something like in your template.
What should I call my file containing XSL code (XSLT code?),
which one sounds more sensible/meaningful.
I know the abbreviation of both of them. But don't know which one to use and where ..
I just now came across these words in w3schools.com
It started with XSL and ended up with
XSLT, XPath, and XSL-FO.
and also saw written "XSL Source code", So what about .. Alejandro's comments .. ?
Now my question reduces to yet more simple version..
Can we call XSLT code as XSL code too? or is it deprecated?
To be nitpicker, I believe XSL is the language and XSLT is a transformation (a piece of code that is written in XSL to transform one XML to another).
So when you're talking of particular pieces of code I think XSLT is more appropriate (just XSLT not XSLT codes), like apha XSLT or so. But when you are talking about language, it should be XSL e.g. XSL skills, XSL code.
This is not only a matter of opinion: just look and see how many questions are in the xslt tag (2299) and how many are in xsl (753) -- the result is clear, isn't it? :)
Related to this in 2010 I proposed that the xsl tag be considered a synonim for the xslt tag. This proposal was voted and approved.
From http://www.w3.org/TR/xslt#section-Introduction
A transformation expressed in XSLT is
called a stylesheet
From http://www.w3.org/TR/xslt20/#what-is-xslt
[Definition: A transformation in the
XSLT language is expressed in the form
of a stylesheet, whose syntax is
well-formed XML [XML 1.0] conforming
to the Namespaces in XML
Recommendation [Namespaces in XML
1.0].]
Leaving aside the formality of the specification, you can call it what you will. With respect to the components of the stylesheet (or transformation): for XSLT 1.0 they are instructions and its contents are templates, for XSLT 2.0 they are declarations and instructions and its contents are sequence constructors
There is no appreciable difference. I use them interchangeably, and so do most people.
Really, does it matter? I'm all for correct terminology, because it usually matters in IT, but in this case you really won't confuse anyone whichever one you use.