<Scheduled>
<xsl:value-of select="//RequestParameters/Identifier/DepartureDate">
</xsl:value-of>
</Scheduled>
In this xslt code iam getting a last character as 'z' in "//RequestParameters/Identifier/DepartureDate" i want to remove z and please help on this.
If the value of //RequestParameters/Identifier/DepartureDate contains 'z' only at the end, you can use substring-before function.
<xsl:value-of select="substring-before(//RequestParameters/Identifier/DepartureDate, 'z')">
edit:
If you want to get the first 10 characters of the value, you can use substring function.
<xsl:value-of select="substring(//RequestParameters/Identifier/DepartureDate, 1, 10)">
In general, you may want to convert an element value in ISO 8601 date format to another format by adding a javascript function to your xslt, and call that function in your Xpath expression.
For instance, when you have added a (javascript) function convertToDate that extracts the date part of the input value in the format yyyymmdd, the Xpath expression
convertToDate (//RequestParameters/Identifier/DepartureDate)
will result in a value
20111016
assuming there is only one DepartureDate element in the input, having value
2011-10-16T09:40:00.000Z
Related
I have a input string like this,without any space
51=2MA011362X17=MG127AJ4015AG1A20=022=M35=U48=9CVRVC449
Here, number before = is key and after is value. From this string I have to fetch value of 17= (basically fetch the value MG127AJ4015AG1A)
I used <xsl:value-of select="substring-before(substring-after(.,'17='), '=')"/> which is giving me result: MG127AJ4015AG1A20, now I am stuck with removing these last 2 numeric values (20). totally confused how this an be achieved.
Final output string should be - MG127AJ4015AG1A
If it is the case that the number at the end will always be two digits, you put your current expression in a variable, and use substring to remove the last two characters, like so:
<xsl:variable name="match" select="substring-before(substring-after(.,'17='), '=')" />
<xsl:value-of select="substring($match, 1, string-length($match) - 2)"/>
I have the following code
<xsl:value-of select="concat(string($var15_cond_result_exists), string($var16_cond_result_exists))"/>
which is concatenating 2 strings. Examle John and Smith to JohnSmith.
What i want is a space between first name and last name.
I can do this with adding ,' ', between them in concat. Howered there is posibility that there is no first name or last name so I don't need the white space.
How can i solve this problem?
Is it possible to use some conditions or there is easier solution.
Wrap the concat in normalize-space() which will trim any excess spaces at the start or end
<xsl:value-of
select="normalize-space(concat(string($var15_cond_result_exists), ' ', string($var16_cond_result_exists)))"/>
Note, you may be able to drop the string function inside the concat. Try this too
<xsl:value-of
select="normalize-space(concat($var15_cond_result_exists, ' ', $var16_cond_result_exists))"/>
You don't say which XSLT version you are using. In XSLT 2.0 you can do
<xsl:value-of select="$var15_cond_result_exists, $var16_cond_result_exists"/>
which will automatically insert a space if and only if both items exist. The conversion to string is automatic in both 1.0 and 2.0.
I have a large XSD I process using several templates to get a new XSD.
In one of the last steps I would like to determine the length of the xml (actually an XSD) that was captured in a variable xsdresult.
Using the string-length function I see a strange length not matching the variable length of xsdresult. Size of string/xsd is over 52000 chars but I see Length: 9862 What am I doing wrong?
<!-- Catch output in variable -->
<xsl:variable name="xsdresult">
<xsl:call-template name="start"/>
</xsl:variable>
<xsl:template name="start">
<xsl:apply-templates/>
</xsl:template>
<!-- Build required doc parts -->
<xsl:variable name="docparts">
<xsl:call-template name="builddocparts"/>
</xsl:variable>
<xsl:template name="builddocparts">
Length: <xsl:value-of select="string-length(normalize-unicode($xsdresult))"/>
</xsl:template>
...
A call to string-length() is equivalent to a call to string-length(.), which in turn coerces the current node to a string, so it's equivalent to string-length(string(.)). The value of the string() function is the string value of the node, which for an element node is the string formed by the concatenation of all descendant text nodes.
If you want to know how the minimum amount of space the serialized XML document will take on disk, given a simple serialization, then you must add:
For each non-empty element, the length of its start-tag: the length of the element type name, plus 2 for the start-tag delimiters < ... >, plus the sum of the lengths of the attribute-value specifications.
For each attribute-value specification, you will need one character for leading whitespace, plus the length of the attribute name, plus the string length of the attribute's value, plus three for the equal sign and quotation marks, plus five characters for each time a quotation mark is replaced by ' or ".
For each non-empty element, the length of its end-tag (length of its element type name plus 3).
For each empty element, the length of its sole tag (length of its element type name, plus length of its attribute-value specifications, plus 3).
For each occurrence of < in the data or in attribute values, three characters for the escaping as <.
For each occurrence of ampersand in the data or in attribute values, four characters for escaping as &.
Not part of the minimum amount, but possibly part of the space you'll need on disk:
The total width of any whitespace added, if you indent the XML structurally.
The number of CDATA marked sections you serialize, times 12 (for <![CDATA[ + ]]>).
The number of characters saved by using CDATA marked sections instead of < and &.
I have an XSLT statement as follows:
<xsl:when test="address1 != ' '">
My incoming XML the address node is as follows:
<address1/>
The node exists and the xsl statement seems to work sometimes, but it doesn't always work, it is giving me inconsistent results. I am checking the address1 node and if it is spaces, then I check address2 node, if it is not spaces I move it up to address1 output field if address1 input is spaces. Our customers are very inconsistent when entering addresses and our vendor requires address1 to be valid. Thanks for any help.
The problem with checking against a string is that you actually check for text within all descendants of the element, so <foo><bar>test</bar></foo> would fail the test foo = '', because the text test exists within the tree.
A more conclusive test is:
address1[not(text()) and not(*)]
This passes only where there is neither text nor child elements within the address element.
The node is empty.
You are testing for it not being a single space ' ', if it is an empty node the test will succeed.
To test that the node is empty you can do this:
<xsl:when test="address1 = ''">
A self-closing tag should have no content, so checking for '' would be the proper way to go. Doing '[space]' implies that the tag is actually <address1>[space]</address1>, which is no longer self closing.
You're not telling us enough about your code for us to reliably tell you what's wrong with it. Don't be so reticent! There could be all sorts of problems that aren't evident from a tiny snippet, e.g. using the wrong context item.
One piece of advice, though: avoid the "!=" operator (which appeared in your example). Usually you want not(author='') rather than author!=''. They mean the same thing if there is exactly one author element, but they have different meanings if there is no author element or if there is more than one. The expression author!='' is true if there is at least one author element whose value is not the empty string; the expression not(author='') is true if there is no author element whose value is the empty string.
To check if an element's string value is non-empty and non-whitespace-only, use:
string-length(normalize-space(address1)) > 0
The standard XPath function normalize-space($s) takes a string $s as an argument and returns another string produced from $s in which all leading and trailing whitespace characters are removed and any group of adjacent interim whitespace characters is replaced by a single space-character.
This means that the result of normalize-space() when applied on a string that contains only white-space characters, is the empty string (having string-length() of 0).
The XPath expression above is testing if the result of applying the normalize-space() function to the string-value of address1 has positive (> 0) length -- this means that the string value of address1 contains at least one non-whitespace character.
What is the difference between <xsl:variable name="test" select="1"/>
and <xsl:variable name="test" select="'1'"/> ?
if both results are result tre fragments.. so basically the two lines of code above are identical?
If so. how do we decide which to use?
The first sample creates a variable of type number with the number value 1, the second a variable of type string with the string value "1". Result tree fragments are not created with your code samples, that would be done with <xsl:variable name="test">1</xsl:variable>.
As #Martin pointed out, the first one binds the variable to a number and the second one to a string.
how do we decide which to use?
Think of the use you will do with that variable. For example, in the first case you will be able to do:
item[$test]
This won't be possible in the second case, unless you use number() function.
As per the comments below, string or number will not make any difference when using any of the comparison operators. Even when comparing against nodes sets or rtfs. You can read this on the specs (a bit verbose) or try some silly test.
What still is evident is the different behavior you can obtain when dealing with node positions. For example, if you have:
<xsl:variable name="number2" select="2"/>
<xsl:variable name="string2" select="'2'"/>
<xsl:variable name="rtf2">2</xsl:variable>
and you have the input like this:
<root>
<test>a</test>
<test>b</test>
</root>
By using:
<xsl:value-of select="/root/test[$rtf2]"/>
<xsl:value-of select="/root/test[$string2]"/>
<xsl:value-of select="/root/test[$number2]"/>
You will get:
aab
while this:
<xsl:value-of select="/root/test[position()=$rtf2]"/>
<xsl:value-of select="/root/test[position()=$string2]"/>
<xsl:value-of select="/root/test[$number2]"/>
will return:
bbb
due to implicit conversion caused by comparison operators.
XPath 1.0 and XSLT 1.0 treat numbers and strings as pretty much interchangeable, with very few exceptions. A notable exception is item[$test]. But "=" behaves slightly differently too: as numbers 4 and 04 are equal, but as strings they are not.
In XPath 2.0 and XSLT 2.0 the type system is much richer and the difference between strings and numbers is much more noticeable: many operations defined on numbers won't work on strings, and vice-versa.
How to decide? If it's all-numeric, you would normally want to use a number, unless it's something like a phone number, where leading zeros are significant, and it's therefore not really a number but a string of digits.