Si pulsa el botón se actualizará la página completa. El usuario podría ir a la región "Lista de entradas" para ver el nuevo contenido.)Lista de entradas
Blog posting DataPower languages explains the different options of how one of DataPower languages can call out to another.
Blog posting XPath 1.0 and XPath 2.0 in a single (concat) statement showed how to use XPath 1.0 (in DataPower XSLT 1.0 processor) and XPath 2.0 (in DataPower XQuery processor) in same XSLT stylesheet (via "dp:xquery-transform()").
GatewayScript allows to evaluate XPath expression (XPath 1.0) by "transform.xpath()" from transform module. Same module "transform.xslt()" allows to execute XSLT. Putting both together with stylesheet from 2nd blog posting mentioned above demonstrates how to evaluate XPath 1.0 and XPath 2.0 expressions in single Gatewayscript.
DataPower has a XSLT 1.0 processor since day 1 long ago (1999), and that provides XPath 1.0.
(There is a wealth of EXSLT as well as DataPower proprietary extension functions/elements)
With 6.0.0.0 firmware DataPower shipped XQuery 1.0 processor as well, and that provides XPath 2.0.
Any valid XPath 2.0 statement is a valid XQuery script by definition.
And there is a HUGE amount of functions and operators in XPath 2.0 (more than 250): http://www.w3.org/TR/xpath-functions/
With 7.0.0.0 firmware released last Friday we got much new exciting stuff (I blogged on GatewayScript before).
Today I want to talk on 3. which allows DataPower XSLT processor to "call out" to XQuery -- nice!
Last August Eric van der Vlist twittered on an XPath expression that allows to tell whether XPath processor is 1.0 or 2.0.
In this tweet I simplified (minimalized?) his expression to (4=5)=/..
This expression just compares false() with an empty nodeset and that is true for XPath 1.0 and false for XPath 2.0.
In my January posting on TOhtml tool for creating the nicely syntax-highlighted source code listings I use in my blog (based on vi's (my favorite editor) TOhtml command), I showed the "answer" to Shakespeare's question from a C- or Java-programmer's perspective:
$ echo "<foobar/>" | coproc2 Shakespeare.xsl - http://dp2-l3:2223 When Shakespeare asked, "To be, or not to be?", he did not provide the answer. But programming can. Well the answer is FF. (2B |~ 2B = FF, bitwise hexadecimal) $
Today I thought again on Shakespeare's question, and think the answer is more likely to be "true" because the question term is a (logic) tautology.
allowed for switching on node-type -- with the help of Michael I got this right. It is a little tricky to check whether a given node is a namespace node or attribute, have a look. This node-type switcher is also part of xpath++ tool
This function just returns the node-type as string, and below stylesheet node-kind.xsl does implement this for DataPower use. See this sample execution with a testcase for each return value, taken from the stylesheet itself (see "document('')" ):
$ echo "<foobar/>" | coproc2 node-kind.xsl - http://dp3-l3:2223 document element attribute text namespace processing-instruction comment $
In posting xs:decimal() https://www.ibm.com/developerworks/mydeveloperworks/blogs/HermannSW/entry/xs_decimal19 it was discussed that xs:decimal() has to be applied to an atomic type, and a solution was provided allowing to apply xs:decimal() to a nodeset. In addition it was mentioned that "XSLT 2.0" needs to be selected as "XSLT Version" in DataPower service's XML Manager's Compile Options Policy.
DataPower xs:decimal supports precision of 18 digits, which can be seen by the following simple experiments. The last three samples produce the following error messages in the log:
... the total precision is therefore 53 bits (approximately 16 decimal digits). ... ... For the next range, from 253 (=9,007,199,254,740,992) to 254, everything is multiplied by 2, ...
Below you can see the output of DataPower, xsltproc, xalan and saxon XSLT processors for numbers with 15 to 18 digits. Reported is the length, the conversion of the input string to number (by XSLT core function number()) as well as the original input string. The last 16 digit number is the lowest (positive) integer with precision loss: