I have a xslt stylesheet with multiple xsl:imports and I want to merge them all into the one xslt file.
It is a limitation of the system we are using where it passes around the xsl stylesheet as a string object stored in memory. This is transmitted to remote machine where it performs the transformation. Since it is not being loaded from disk the href links are broken, so we need to remove the xsl:imports from the stylesheet.
Are there any tools out there which can do this?
You can use an XSL stylesheet to merge your stylesheets. However, this is equivalent to using the xsl:include element, not xsl:import (as Azat Razetdinov has already pointed out). You can read up on the difference here.
Therefore you should first replace the xsl:import's with xsl:include's, resolve any conflicts and test whether you still get the correct results. After that, you could use the following stylesheet to merge your existing stylesheets into one. Just apply it to your master stylesheet:
<?xml version="1.0" ?>
<xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
version="1.0">
<xsl:template match="xsl:include">
<xsl:copy-of select="document(#href)/xsl:stylesheet/*"/>
</xsl:template>
<xsl:template match="#*|node()">
<xsl:copy>
<xsl:apply-templates select="#*|node()"/>
</xsl:copy>
</xsl:template>
</xsl:stylesheet>
The first template replaces all xsl:include's with the included stylesheets by using the document function, which reads in the file referenced in the href attribute. The second template is the identity transformation.
I've tested it with Xalan and it seems to work fine.
It is impossible to include imported stylsheets into the main file without breaking import precedence. For example, you define a top-level variable in an imported stylesheet and redefine it in the main file. If you merge two files into one, you’ll get two variables with the same name and import precedence, which will result in an error.
The workaround is two replace xsl:import’s with xsl:include’s and resolve any conflicts. After that you are safe to replace xsl:include instructions with the corresponding files’ contents, because that is what XSLT-processor does:
The inclusion works at the XML tree level. The resource located by the href attribute value is parsed as an XML document, and the children of the xsl:stylesheet element in this document replace the xsl:include element in the including document. The fact that template rules or definitions are included does not affect the way they are processed.
A Manual merge is probably going to be the best option.
The main consideration will probably be to make sure that the logic for matching templates works in the combined stylesheet.
Why would you want to? They're usually seperated for a reason afterall (often maintainability)
You could always write the merge yourself - read the XSL files in, select the template items you're interested in and write to a new master XSL file...
import multiple xsl in single xsl
<xsl:import href="FpML_FXOption_Trade_Template1.xsl"/>
<xsl:apply-imports/>
<calypso:keyword>
<calypso:name>DisplayOptionStyle</calypso:name>
<calypso:value>Vanilla</calypso:value>
</calypso:keyword>
<xsl:import href="FpML_FXOption_Trade_Template2.xsl"/>
<xsl:apply-imports/>
Related
I'm trying to use xslt to change namespaces an xml file. I was hoping to get something a bit closer than I have so far but I'm going around in circles so I thought I'd ask the question a little earlier than I ordinarily would...
My XML file is
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<ns2:apple xmlns:ns2="http://veg.com/app/api/apple" xmlns:ns1="http://veg.com/app/api" xmlns:ns3="http://veg.com/app/api/apple/red"
xmlns:ns4="http://veg.com/app/banana" xmlns:ns5="http://veg.com/app/api/pear" xmlns:ns6="http://veg.com/app/api/orange"
ns1:created="2016-05-23T16:47:55+01:00" ns1:href="http://falseserver:8080/app/api/apple/1" ns1:id="1">
<ns2:name>granny smith</ns2:name>
<ns2:flavour>sweet</ns2:flavour>
<ns2:origin>southwest region</ns2:origin>
</ns2:apple>
The only part I want to change are the urls in the namespace atributes of the root element to (veg to fruit)
<ns2:apple xmlns:ns2="http://fruit.com/app/api/apple" xmlns:ns1="http://fruit.com/app/api" xmlns:ns3="http://fruit.com/app/api/apple/red"
xmlns:ns4="http://fruit.com/app/banana" xmlns:ns5="http://fruit.com/app/api/pear" xmlns:ns6="http://fruit.com/app/api/orange"
ns1:created="2016-05-23T16:47:55+01:00" ns1:href="http://falseserver:8080/app/api/apple/1" ns1:id="1">
I've tried a few things but have failed spectacularly so far. My last attempt was
<xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
<xsl:template match="*">
<xsl:element name="{local-name()}" namespace="http://fruit.com/app/api/apple">
<xsl:apply-templates select="#*|node()"/>
</xsl:element>
</xsl:template>
<xsl:template match="#*|node()">
<xsl:copy>
<xsl:apply-templates select="#*|node()"/>
</xsl:copy>
</xsl:template>
</xsl:stylesheet>
which has given me a ridiculous result -
<?xml version="1.0" encoding="UTF-8"?><ns0:apple xmlns:ns0="http://fruit.com/app/api/apple" ns1:created="2016-05-23T16:47:55+01:00" ns1:href="http://falseserver:8080/app/api/apple/1" ns1:id="1">
<ns1:name xmlns:ns1="http://fruit.com/app/api/apple">granny smith</ns1:name>
<ns2:flavour xmlns:ns2="http://fruit.com/app/api/apple">sweet</ns2:flavour>
<ns3:origin xmlns:ns3="http://fruit.com/app/api/apple">southwest region</ns3:origin>
</ns0:apple>
I think my first and biggest issue is trying to do the correct match. As you can see I have resorted to a * but this is out of desperation rather than because I think it's the right way to go! I'm also not sure why it drops all the other namespace attributes from the tag bu this also seems to happen quite consistently in all the ways I've tried so far. I've no idea how I've managed to get the new 'tag namespaces' in the document but I suspect if I could at least get the start of the xsl doc correct I'd be much closer to the answer...
In the code provided (your "spectacular failure") you have left the XSLT processor to think up new prefixes. When you don't specify a prefix in xsl:element, an XSLT 1.0 processor is expected to dream one up. This changes in XSLT 2.0, which is required to put the element in the default namespace. If you want to use the prefix ns2, then specify
<xsl:element name="ns2:{local-name()}" namespace="http://fruit.com/app/api/apple">
which will work in either release (except that in XSLT 1.0, processors have blanket permission to change namespace prefixes any way they want: but most processors don't do this in ordinary circumstances).
This will work for the namespaces that are actually used in element names. It will drop namespaces that are unused. Your example appears to retain some unused namespaces from the source document, but changing the prefix.
If you know that the root element of your document is always ns2:apple, then generate that element in the output using a literal result element with all the desired namespaces.
If you don't know the name of the root element in advance, then controlling its namespace declarations is quite hard to achieve in XSLT 1.0 (and rarely needed!). In XSLT 2.0 you can do it using the xsl:namespace instruction.
Some of my stylesheets are a bit large and some of their parts are repeating. I would like to use XInclude for them—which would allow me to separate them aside the whole stylesheet. I can’t use xsl:import or xsl:include here because I need to inject them into the specific place for generating bookmarks and active links (for XSL-FO).
If I use:
<xi:include href="/db/apps/tested-bunny/resources/xsl-fo/common/bookmark-tree.xml/>
… the .fo file produced really includes the part. However, the part is untranslated, which means it is there as is in the source. The XSL-FO processor thus ignores it and the pdf result is without bookmarks.
As for the separated part—I saved it as a regular XML file with two namespaces declared in the root element:
<fo:bookmark-tree xmlns:xsl="http://www.w3.org/1999/XSL/Transform" xmlns:fo="http://www.w3.org/1999/XSL/Format">
<xsl:if test="$head-level ge '1'">
...
If I try to include the same code snippet in a form of XSL stylesheet, it is the same—it is injected there properly but it does not add its functionality to the whole stylesheet, it is there still untranslated.
Is there any specific practice or limitation I am not aware of? How to do that properly?
For me, the working solution was not XInclude but xsl:include and calling the template at the proper time:
...
</fo:declarations>
<!-- Bookmarks from the external stylesheet -->
<xsl:call-template name="bookmark-tree"/>
<fo:page-sequence master-reference="title-page">
...
I created the proper stylesheet. The important thing was to set the root element to the current context:
<xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform" xmlns:fo="http://www.w3.org/1999/XSL/Format" version="2.0">
<xsl:template name="bookmark-tree" match=".">
<fo:bookmark-tree>
...
And of course, it was necessary to include the stylesheet into the one where I call the template:
<xsl:include href="common/bookmark-tree.xsl"/>
For now, I consider this question as answered.
I would seek this your guidance for doubt in XSLT. In my current project there is a requirement to create many XSLT files. In these transformations, there are few common steps performed; for.eg. changing uppercase of an element value from input xml. I'm currently using the below code in an XSLT, so if there are 50 XSLT being created then this code will be duplicated.
<xsl:variable name="smallcase" select="'abcdefghijklmnopqrstuvwxyz'" />
<xsl:variable name="uppercase" select="'ABCDEFGHIJKLMNOPQRSTUVWXYZ'" />
<xsl:message>UPPERCASE is <xsl:value-of select="translate($MsgType, $smallcase, $uppercase)" /></xsl:message>
Requesting your advice on how to avoid code duplication. Can I create a common XML file such as utility and declare the variables uppercase and smallcase and shall I call these variables inside the xslt. Similar to other prog. lang like java where I can declare a common function globally and use it in different classes. Basically I would like to know whether it is possible to declare globally and use it in all the xslt.
I would use <include/> to include the XSLT file with all your global variables defined.
See also http://www.w3.org/TR/xslt#element-include
Put all your variables into the file "my_global_variables.xsl":
<?xml version="1.0" encoding="UTF-8"?>
<xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform" version="1.0">
<xsl:variable name="myVariable" select="'xyz'"/>
<!-- more variables to add -->
</xsl:stylesheet>
Your main stylesheet looks like this then, including the "my_global_variables.xsl":
<?xml version="1.0" encoding="UTF-8"?>
<xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform" version="1.0">
<xsl:include href="my_global_variables.xsl"/>
<xsl:template match="/">
</xsl:template>
</xsl:stylesheet>
There is also the <import> element with which you can import stylesheets. An imported style sheet has lower precedence than the importing style sheet though - so in your case I would use <include>.
Requesting your advice on how to avoid code duplication. Can I create
a common XML file such as utility and declare the variables uppercase
and smallcase and shall I call these variables inside the xslt.
<xsl:import> and <xsl:include> are the two XSLT instructions especially designed for this task.
Global variables (children of an xsl:stylesheet element) in a stylesheet module are accessible in the stylesheet that includes this stylesheet. The rules with importing are a little bit more complicating, but if there are no naming conflicts between global variables from imported stylesheets, they are all accessible from the importing stylesheet.
Finally, I recommend not to use www.w3schools.com -- see why at: http://www.w3fools.com
I would like to make certain lines of a DocBook table of contents bold based on whether the particular <section> has a certain attribute defined. This is easy by adding an <xsl:if test="..."> statement to the DocBook XSL (fo/autotoc.xsl lines 187-230 -- this is for output to PDF using XMLMind).
I'm wondering, though, if it's bad practice to edit the DocBook XSLs themselves. I have other customizations in a separate XSL of my own, mostly setting parameters, but I can't imagine how I would introduce this conditional logic--based on which line of the TOC is currently being processed--without putting some sort of code in the originals. Any thoughts? How do you upgrade to a newer DocBook XSL after making changes?
Import the docbook stylesheets from your own XSLT. Then, (re)define the Docbook template that you want to "override".
Since your template will be the highest in the import tree, it will take precedence.
By doing it that way you don't have to modify any of the core docbook XSLT files. It will make upgrades of the Docbook stylesheets easier in the future.
<?xml version="1.0" encoding="ISO-8859-1"?>
<xsl:stylesheet version="1.0"
xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
<xsl:import href="xsl/fo/docbook.xsl"/>
<xsl:template match="template-that-you-need-to-redefine">
...
</xsl:template>
</xsl:stylesheet>
I have a set of XML files that I am processing with an XSL transform. They have a default namespace, so my XSL transform must contain the declaration:
xpath-default-namespace="urn:CZ-RVV-IS-VaV-XML-NS:data-1.2.2"
The problem is that this value changes from time to time, and my transform suddenly stops working, until I look at an example from the new file, extract this namespace ID and put it in the transform, whereby the transform stops working for old files. Is there a way to pass this as a parameter, or set it somehow at runtime? I have tried the parameter syntaxes that I looked up in various tutorials, but none have worked for this particular use.
I have searched all sorts of forums and found references to namespace-agnostic coding of XSL, but not figured out how to do it. Ian Williams' book "XSLT and Xpath" states that the default namespace must be declared, or you get nothing in the output stream, which is how it has worked for me. But I really don't want to have to change this by hand regularly, I want to give the user something that will work, without needing constant attention from me.
The only 100% reliable way I have invented so far is to use a standard programming language to open both the XML source and XSL transform as text files, extract the URI from the XML source, paste it into the XSL transform, close both files and then, finally run the actual transform. This works, but is incredibly dorky, at least to my taste. How can I better deal with changing default namespaces?
Pete
The value of xpath-default-namespace must be a static URI, so you'll have to pre-process the stylesheet if you want it to vary. One way to do that would be to use XSLT. Apply the following meta-stylesheet to your primary stylesheet each time, and then invoke the pre-processed result instead.
<xsl:stylesheet version="2.0"
xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
<!-- Pass in the new namespace URI as a stylesheet parameter -->
<xsl:param name="new-uri" required="yes"/>
<!-- By default, copy everything as is -->
<xsl:template match="#* | node()">
<xsl:copy>
<xsl:apply-templates select="#* | node()"/>
</xsl:copy>
</xsl:template>
<!-- But update the value of #xpath-default-namespace -->
<xsl:template match="#xpath-default-namespace">
<xsl:attribute name="{name()}" namespace="{namespace-uri()}">
<xsl:value-of select="$new-uri"/>
</xsl:attribute>
</xsl:template>
</xsl:stylesheet>
This is a bit of a strange use case though, because namespaces weren't really designed to be so dynamic. They were designed to qualify names, i.e. make up part of a name. When you look at it that way, dynamic namespaces don't make a lot of sense. Imagine a database whose table and field names arbitrarily changed every once in a while, forcing you to rewrite all your SQL scripts to keep up with the changes. That's what this is akin to.
Have you tried defining a stylesheet parameter <xsl:param name="xpdn"/> and using it in the stylesheet declaration or top level template declaration as in
<xsl:template match="...." xpath-default-namespace="$xpdn">
I can't find anything in the spec that says this won't work (but I'm not in a position to try it just now).