I am using the XML file here
http://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xml
And I have written this code
<xsl:for-each select="registry/record">
However it never finds anything because of this line in the XML
<registry xmlns="http://www.iana.org/assignments" id="service-names-port-numbers">
If I change that to
<registry>
It works, however I cannot change the XML, I must change the XSLT. What can I do to make it work? I just need to find those records.
Thanks.
XSLT and XPath are namespace-aware. Unfortunately they don't have any notation for setting a default namespace for the path, so you have to use an explicit prefix bound to the namespace.
If you aren't familiar with XML Namespaces, do review them. They're important.
Taking your specific example, here's a simplified version of the start of the SNTP document
<registry xmlns="http://www.iana.org/assignments" id="service-names-port-numbers">
<title>Service Name and Transport Protocol Port Number Registry</title>
<category>Service Names and Transport Protocol Port Numbers</category>
<updated>2014-02-06</updated>
<xref type="rfc" data="rfc6335"/>
<expert> ... names of experts ... </expert>
<note> ... usage notes ... </note>
<record>
<protocol>tcp</protocol>
<xref type="person" data="Jon_Postel"/>
<description>Reserved</description>
<number>0</number>
</record>
</registry>
The xmlns="http://www.iana.org/assignments" is a default namespace binding. All elements in this document will be in that namespace unless they have a prefix bound to another namespace or another xmlns= is used to change the default for them and their children.
Your XPaths and Match Expressions MUST reference this namespace, or they won't work.
Change
<xsl:for-each select="registry/record">
to
<xsl:for-each select="assignments:registry/assignments:record"
xmlns:assignments="http://www.iana.org/assignments">
(You can use a shorter prefix than assignments; I'm just trying to make this as clear as possible. You can also bind the prefix higher in your XSLT document -- typically, on the <xsl:stylesheet> element -- so it's available throughout the stylesheet rather than just in this one place.)
This will work, assuming the rest of your code is correct.
Also: In general, <xsl:for-each> tends to be overused. In general, unless this is a place where you really do need to do different processing than anywhere else in the stylesheet, you should instead be using <xsl:apply-templates> so the normal template-matching rules can apply. Otherwise you're making the stylesheet hard to extend and maintain. XSL is a rule-matching, nonprocedural language; learn to use it that way.
Related
I am working with a project where I need to create a html-file supporting several languages from an xslt-transformation. I have read several articles around this, and also looked at previous questions here in stackoverflow, like this one:
xslt localization
And the solution to put the translations in a separate xml document works just as I want it to. But I wonder if there exists any standardized/best practice for the "translate.xml" file? In the post referenced above, the following is given as an example:
<strings>
<string language="en" key="ContactDetails">Contact Details</string>
<string language="sv" key="ContactDetails">Kontaktuppgifter</string>
[...]
</strings>
As I said, the solution suggested with using keys retrieve the strings from the transalte.xml works as I want it to, but I like to use standards if they are available, so my question is if there is a standardized schema for these types of xml files, or some kind of best practice on the naming of tags etc in such a "translate.xml"?
Good question!
Yes, there is a standardized way of dealing with languages. Use the xml:lang attribute. The namespace magically exists in any XML document and is part of the core XML specification. It is defined to take a language specifier according to RFC-4646. These are the often-seen specifiers like en, en-US, es, es-BR, specifying the main language and the language variant.
The way it works is a bit like namespaces. If you define it on an element, then it is inherited by all descendants of that element, unless you redefine it, or undefine it to denote language-indepent elements.
For instance:
<text xml:lang="en">
We are
<t xml:lang="en-US">organizing</t>
<t xml:lang="en-GB">organising</t>
a conference on the effects of
<t xml:lang="en-US">color</t>
<t xml:lang="en-GB">colour</t>
in December this year.
</text>
Using a query language, i.e. XSLT, with a copy-idiom, this works excellently together with the lang() function, which takes the applicable language from the nearest ancestor or self and returns boolean true if found. It will also find the language variant like en-US if you set the main language, like en.
The following assumes XSLT 1.0, but works with 2.0 and 3.0 as well (this code was kindly corrected by Michael, see comments):
<!-- match English US language and default en -->
<xsl:template match="t[lang('en-US') or lang('en')">
<xsl:apply-templates />
</xsl:template>
<!-- remove any other <t> -->
<xsl:template match="t" />
Note: always set a default language on the outermost element, as lang() will return false if no language is found at all. You could test for this with the expression lang(''), which will return false only if no language was set at all.
About your XML files, if you have one file per language, and don't mix and match like suggested above, you can still use the same approach by setting xml:lang on the root element. Since this will then be inherited throughout the whole tree, you can still use the lang() function.
I have one XML input file in which I am getting some Namespaces which I wanted to replace from another using XSLT. Actually I am new XSLT so not able to find proper solution. below is the XML input payload and Output payload which I want. Could anyone help me on that.
Input Payload:
<ns:createOrderResponse xmlns:ns="http://services.oms.ecom.ecc.com"><ns:return type="com.ecc.ecom.oms.beans.xsd.CreateOrderResponse"><ns:omsGeneratedOrderId xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:nil="true" /><ns:responseCode>99</ns:responseCode><ns:responseDesc>INVALID ORDER</ns:responseDesc><ns:sellerSiteId>10196</ns:sellerSiteId><ns:serverProcElapsedTime>8</ns:serverProcElapsedTime><ns:siteGeneratedOrderId xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:nil="true" /><ns:subResponse><responseCode xmlns="http://beans.oms.ecom.ecc.com/xsd">1144</responseCode><responseDescription xmlns="http://beans.oms.ecom.ecc.com/xsd">Order Total mismatch</responseDescription></ns:subResponse><ns:subResponse><responseCode xmlns="http://beans.oms.ecom.ecc.com/xsd">1147</responseCode><responseDescription xmlns="http://beans.oms.ecom.ecc.com/xsd">Order Grand Total and sum of OrderItem Grand Total mismatch</responseDescription></ns:subResponse><ns:transactionNumber>0717299145</ns:transactionNumber></ns:return></ns:createOrderResponse>
Desired Output:
<ns:createOrderResponse xmlns:ns="http://services.oms.ecom.ecc.com"><ns:return type="com.ecc.ecom.oms.beans.xsd.CreateOrderResponse"><ns:omsGeneratedOrderId xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:nil="true" /><ns:responseCode>99</ns:responseCode><ns:responseDesc>INVALID ORDER</ns:responseDesc><ns:sellerSiteId>10196</ns:sellerSiteId><ns:serverProcElapsedTime>8</ns:serverProcElapsedTime><ns:siteGeneratedOrderId xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:nil="true" /><ns:subResponse><responseCode xmlns="http://services.oms.ecom.ecc.com">1144</responseCode><responseDescription xmlns="http://services.oms.ecom.ecc.com">Order Total mismatch</responseDescription></ns:subResponse><ns:subResponse><responseCode xmlns="http://services.oms.ecom.ecc.com">1147</responseCode><responseDescription xmlns="http://services.oms.ecom.ecc.com">Order Grand Total and sum of OrderItem Grand Total mismatch</responseDescription></ns:subResponse><ns:transactionNumber>0717299145</ns:transactionNumber></ns:return></ns:createOrderResponse>
Basically I wanted to replace:
Namespace :http://beans.oms.ecom.shc.com/xsd
from
Namespace :http://services.oms.ecom.ecc.com
CAVEAT: The following is untested but demonstrates the ideas.
If you know which specific elements and attributes to expect, that's relatively easy -- it's the same as any other "when you see this element, output this other element instead" template, recursing to cover the whole document. Start with the identity stylesheet and add appropriate templates of the form:
<xsl:template match="wrongnamespace:fred"
xmlns:wrongnamespace="http://services.oms.ecom.ecc.com">
<rightnamespace:fred xmlns:rightnamespace="http://beans.oms.ecom.shc.com/xsd">
<xsl:apply-templates/>
</rightnamespace:fred>
</xsl:template>
and (for attributes)
<xsl:template match="#wrongnamespace:george"
xmlns:wrongnamespace="http://services.oms.ecom.ecc.com">
<xsl:attribute name="ns:george" value="."
namespace="http://beans.oms.ecom.shc.com/xsd"/>
</xsl:template>
... and so on.
If you don't know what elements or attributes to expect, this becomes uglier. In XSLT 1.0 and XPath 1.0 there's no easy way to say "any element node" (though I believe that was fixed in the 2.0 version of these specs). Sticking with 1.0 because it's more widely supported, the easiest solution is to use priorities: have a higher-priority template that catches the attributes, then have another template which handles other namespaced nodes (which would therefore be elements).
<xsl:template match="#*[namespace-uri(.)="http://services.oms.ecom.ecc.com"
priority="1">
<xsl:attribute name="concat('ns:',localname(.))" value="."
namespace="http://beans.oms.ecom.shc.com/xsd"/>
</xsl:template>
<xsl:template match="node()[namespace-uri(.)="http://services.oms.ecom.ecc.com"
priority="1">
<xsl:element name="concat('ns:',localname(.))"
namespace="http://beans.oms.ecom.shc.com/xsd">
<xsl:apply-templates/>
</xsl:element>
</xsl:template>
Again, adding these to the canonical identity stylesheet will do what you need; it'll catch and change these two cases while copying everything else unaltered.
CAVEAT: THIS WILL NOT CHANGE URIS APPEARING IN STRINGS. You could add a template which looks for text() nodes containing the old URI and outputs the new one instead; I'm leaving that as an exercise for the reader.
CAVEAT: THIS WILL NOT CHANGE NAMESPACE NODES. You may wind up with leftover declarations of the old prefix and namespace. Another template could be added to clean that up; this too is left as an exercise for the reader.
That should give you enough to get you started. Have fun. Programming in XSLT does require learning to think in terms of rules and replacements rather than procedures, but when you get used to that it can be a very expressive tool.
(Standard plug: If you want an off-the-shelf tested solution, you can probably find one on Dave Pawson's XSL FAQ website. That's a resource you really need to be aware of if working in XSLT; it'll save you a lot of work, and it has some solutions that are very clever and very non-obvious.)
I have an XSLT stylesheet that produces some output in XML. I want to processes that output with another stylesheet. Is there a way to tell the latter stylesheet to "run and use" the results from the former?
There is not, as far as I know, a standard way to tell an XSLT processor to run another stylesheet on given input and do something with the output. In some cases you can process the input against one set of templates and save the result in a variable, then apply a different set of templates to the value of the variable, something like this:
<xsl:template match="/">
<xsl:variable name="temp">
<xsl:apply-templates mode="first-pass"/>
</xsl:variable>
<xsl:apply-templates select="$temp" mode="second-pass"/>
</xsl:template>
This assumes you're running XSLT 2.0. In XSLT 1.0 you will need a processor that supports the node-set extension (many do), and you'll need to change the reference to $temp to something like exslt:nodeset($temp).
As you will perceive, this won't work very well if your two stylesheets both use the default mode and operate on overlapping sets of element types. So some XSLT processors have added extensions to provide the kind of functionality you describe (see, for example, discussions of the Xalan pipe:pipeDocument extension element).
Of course, you can also handle the pipe outside of XSLT. The simplest way to do it depends upon the environment you are running in.
If you're running XSLT from an operating system shell and your XSLT processor accepts input on stdin, you can pipe the output from one stylesheet into the other:
xsltproc a.xsl in.xml | xsltproc b.xsl - > out.xml
And as mohammed moh has already pointed out, many scripting environments make it possible to do similar things: he mentions PHP, and of course there's XProc.
yes You can. You must Transforms the source node to a DOMDocument I don't Know What is your Programming Language . For Example in php is transformToDoc() after Transforms You Can Run A New XSLT Stylesheet On DOMDocument Output
What does a namespace do in XSLT when a url is provided such as:
xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
does this attempt to make a connection to the internet?
No; it just so happens that the specification for XML Namespaces (see W3C XSL Namespace specifications) are URI's.
They work in exactly the same way that namespaces in other languages do; they help uniquely identify things with the same names but in different contexts.
You can prove that no attempt is made to retrieve the resource by using a HTTP Monitor on your machine while loading or using the XSL Transformation - this answer has many good suggestions.
No.
Whatever the namespace is in a xsd, an xslt or any other xml file, there is no internet request.
The namespace is used to qualified your xml element.
When you conduct an XSLT transformation, the XSLT engine validates the XSLT file. It performs many checks, such as the root element being named stylesheet, etc. The engine must also be able to discern literal result elements (like <table>) from XSLT-specific elements (like <xsl:stylesheet>).
An element is recognized as XSLT-specific when it resides in the XSLT namespace. The value of the URI you posted (http://www.w3.org/1999/XSL/Transform) is simply a convention that makes it clear we're talking about XSLT. The prefix being defined (xsl) is the prefix used in the XSLT file to qualify the XSLT elements. You can use another prefix if you choose, provided you map it to the XSLT namespace.
Note that it's actually just a URI (an identifier), not a URL (a locator). There is no HTTP request to locate anything, it just identifies an abstract concept (in this case "XSLT").
is it at all possible to 'pre-proccess' in XSLT?
with preprocessing i mean updating the (in memory representation) of the source tree.
is this possible, or do i need to do multiple transforms for it.
use case:
we have Docbook reference manuals for out clients but for certain clients these need different 'skins' (different images etc). so what i was hoping to do is transform the image fileref path depending on a parameter. then apply the rest of the normal Docbook XSL templates.
Expanding on Eamon's answer...
In the case of either XSLT 1.0 or 2.0, you'd start by putting the intermediate (pre-processed) result in an <xsl:variable> element, declared either globally (top-level) or locally (inside a template).
<xsl:variable name="intermediate-result">
<!-- code to create pre-processed result, e.g.: -->
<xsl:apply-templates mode="pre-process"/>
</xsl:variable>
In XSLT 2.0, the value of the $intermediate-result variable is a node sequence consisting of one document node (was called "root node" in XSLT/XPath 1.0). You can access and use it just as you would any other variable, e.g., select="$intermediate-result/doc"
But in XSLT 1.0, the value of the $intermediate-result variable is not a first-class node-set. Instead, it's something called a "result tree fragment". It behaves like a node-set containing one root node, but you're restricted in how you can use it. You can copy it and get its string-value, but you can't drill down using XPath, as in select="$intermediate-result/doc". To do that, you must first convert it to a first-class node-set using your processor's node-set() extension function. In Saxon 6.5, libxslt, and 4xslt, you can use exsl:node-set() (as in Eamon's answer). In MSXML, you'd need to use msxsl:node-set(), where xmlns:msxsl="urn:schemas-microsoft-com:xslt", and in Xalan, I believe it's called xalan:nodeset() (without the hyphen, but you'll have to Google for the namespace URI). For example: select="exsl:node-set($intermediate-result)/doc"
XSLT 2.0 simply abolished the result tree fragment, making node-set() unnecessary.
This is not possible with standards compliant XSLT 1.0. It is possible in every actual implementation I've used, however. The extensions with which to do that differ by engine, however. It is also possible in standard XSLT 2.0 (which is in any case much easier to work with - so if you can, just use that).
If your xslt processor supports EXSLT, the exsl:node-set() function does what you're looking for. msxml has an identically named extension function as well (but with a different namespace uri, the functions are unfortunately not trivially compatible).
Since you are trying to generate slightly different output from the same DocBook XML source, you might want to look into the "profiling" (conditional markup) support in DocBook XSL stylesheets. See Chapter 26 in DocBook XSL: The Complete Guide by Bob Stayton:
Profiling is the term used in DocBook
to describe conditional text.
Conditional text means you can create
a single XML document with some
elements marked as conditional. When
you process such a document, you can
specify which conditions apply for
that version of output, and the
stylesheet will include or exclude the
marked text to satisfy the conditions.
This feature is useful when you need
to produce more than one version of a
document, and the versions differ in
minor ways.
For example, to use different images for, say, Windows and Mac versions of the same document, you might have a DocBook XML fragment like this:
<figure>
<title>The Foo dialog</title>
<mediaobject>
<imageobject os="windows">
<imagedata fileref="screenshots/windows/foo.png"/>
</imageobject>
<imageobject os="mac">
<imagedata fileref="screenshots/mac/foo.png"/>
</imageobject>
</mediaobject>
</figure>
Then, you would use the profiling-enabled versions of the DocBook XSL stylesheets with the profile.os parameter set to windows or mac.
Maybe you should use XSLT "OOP" methods here. Put all the common templates to all clients in a stylesheet, and create an stylesheet for each client with specific templates overriding common ones. Import the common stylesheet within the specific ones with xsl:import, and you'll do only one processing by calling the stylesheet corresponding to a client.