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.
Related
I know that the input of an XSLT processor is a source XML document that will be transformed into a target XML document.
In my case, I haven't a source XML document but I have a source XML-SCHEMA and I want to know through the XSLT document information about the mappings between the source XML-SCHEMA and the target one.
Thus, I have the idea of executing or maybe parsing the XSLT on the source XML-SCHEMA in order to get this information.
I'm really confused about the difference between execute and parse an XSLT document.
I think that to execute an XSLT document, an XSLT processor firstly parses it to transform it to another internal representation.
What is this internal representation??
I really need your help
I'm really confused about the difference between execute and parse an
XSLT document.
To parse a language, including XML, is to analyse it into parts.
To execute a language, including XSLT, is to perform the instructions specified by the language.
It does not make sense to talk about executing XML because XML itself specifies no instruction.
It does make sense to talk about validating XML against the grammar given by its XSD.
I think that to execute an XSLT document, an XSLT processor firstly
parses it to transform it to another internal representation. What is
this internal representation??
You do not need to know an XSLT processor's internal representation because that is an implementation detail.
You do need to know that an XSLT processor parses an input XML document, executes an XSLT transformation, and generates output. (It also parses the XML that represents the XSLT, but that's beside the point.)
The input XML document typically is not an XSD. You might want to consider the XSD associated with the input XML document in order to anticipate allowed input variations. In rare circumstances you might want to transform the XSD itself in some way, and you can do so since an XSD is represented in XML. In other rare circumstances, you might want to transform XSLT itself in some way, and you can do so since XSLT is also represented in XML. But, normally, the input to an XSLT transformation is a mundane XML document instance, not an XSD, and not other XSLT.
I have a situation where I am processing XML that conforms to one of two DTDs. Is there a way to use XSL to evaluate the DTD specified in the XML file and then call an appropriate XSLT for that DTD? I'm imaging that I would have, for example, dtd1.xsl and dtd2.xsl, where each one had been developed to transform XML conforming to two different DTDs. Another XSL file would first look at the DTD of the incoming XML file and based on that determine if dtd1.xsl or dtd2.xsl should be used to transform the XML.
I understand that there are many ways to do this in code outside of XSL, but I am looking specifically for an XSL solution.
An XML document contains another XML element, which is wrapped in CDATA.
How can the wrapped XML be used for XSL and XSL-FO transformation (version 1)?
If you are willing to take multiple transformation steps then it is possible. Output the relevant section with disable-output-escaping to turn the escaped XML into valid XML. Process it in a subsequent step.
It does require the escaped XML to be well-formed. And some parsers require the intermediate result to be serialized (to disk or else) first to make sure the escaped XML is properly unescaped before it enters the subsequent transformations.
This is not possible with standard XSLT 1.0 or 2.0, in a single transformation.
It can be done using Saxon 9 Professional Edition or Enterprise Edition. These products have a saxon:parse() extension function. Or use the XPath 3.0 parse-xml() function, which is also supported by recent versions of Saxon PE/EE.
As #grtjn points out, it is possible to do it with a two-pass process. Stylesheet 1 turns the CDATA-wrapped text into parseable XML (using <xsl:value-of select="whatever" disable-output-escaping="yes"/>). Stylesheet 2 then processes the serialized result produced by stylesheet 1.
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.
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.