Recently I got a stylesheet with really HUGE number of arguments in a concat() function.
My first approach of determining the arity was not nice and needed handwork, but did give the result I needed.
Later I learned from our XQuery team that XPath 2 has a much simpler solution for that:
Just replace concat(...) by count( (...) ) making the argument list an XPath 2 sequence and applying the count() function.
With v6.0 firmware DataPower has an XQuery 1.0 compiler, so you can evaluate with DataPower.
The result is "12", which you can see live evaluated on try.zorba.io (I do like the "Share" button):
HermannSW 2700006U54 Etiquetas:  stylesheet xslt extension function profiling datapower 4.322 vistas
I do need a little helper function which converts a "byte" value represented by two hexadecimal digits into a number from 0-255.
Since this function will get called very often, choosing "the right" solution here is key.
This posting describes how DataPower stylesheet profoiling helped to identify the best alternative.
First I did come up with different solutions for solving the given task.
Next I just did put them into a stylesheet that exercises each function once.
Then I made the XML manager of coproc2 service to do stylesheet profiling by selecting a Profiling Rule in its Compile Options policy.
After flushing that XML manager ("profile", resets the counters) and sending 10000 requests I looked up "Status->XML Processing->Stylesheet Profiles".
Exercising the 10000 request was done this way:
Find the screenshots for inputs "00" , "99", "AA" and "FF" here (click to open big view):
This is just the table showing the measured times (on a 9004 XI50, reported in milli seconds , but with sub nano second precision):
The increased values for *func:hexdig2num* are due to the fact that digit comparisons are done sequentially.
The last column gives just the values for doubled number of calls.
The worst case wrt time is input 'FF' which enforces quite some <xsl:when>s tests.
And the winner is "hex2num3 with hexdig2num3":
(4+24)/10000 = 2.8 [microsecond/call]
Here is the testing stylesheet:
In yesterday's developerWorks DataPower forum thread
customer complained that DataPower XSLT processor runs out of memory while processing a string of size 4MB:
It turned out that he used functions from my smtp posting in this blog.
And it turns out that a simple helper function I provided (
was not implemented according "Doing recursion right" technique mentioned in my 2010 WSTE webcast (slide 5).
Since DataPower XSLT processor does not provide tail-recursion optimization use of divide-and-conquer technique is required.
This recursive function runs out of stack space because a 4MB string results in more than 50.000 lines -- too much for recursion call-depth.
This is the devide-and-conquer technique which solves the problem easily -- determine $mid as offset where to split, "near" the middle (multiple of 76):
What can be learned from this?
Always implement "little helper functions" as efficient as possible -- you never know how others make use of them ... :-)
HermannSW 2700006U54 Etiquetas:  xslt des extension function ecb xalan datapower cbc mode 2 Comentarios 7.569 vistas
In a developerWorks DataPower Forum thread the question was raised on how to do ECB mode DES encryption with DataPower.
The answers were two-fold:
Find the implementation with a sample from "The DES Algorithm Illustrated" in action, portable for DataPower and xalan use:
A 64bit des:encrypt-blk() call takes roughly 3ms, which means that you do not want to apply that on big data.
The implementation works of 01-strings, hexTObin and other conversion functions included.
This reminds me 5.5 years back when I worked in Smartcard development department in Boeblingen Lab.
The person responsible for side channel attacks left IBM and I was the first who raised the hand for the equipment:
What was easy to do was to break triple DES on cards without randomization counter-measure based on statistical analysis of several thousand measurements.
What I heard about is the single request break of RSA private keys in early smardcards.
The code for doing exponentiation in that cards was "efficient", it did compute
We did not have the equipment to cut reader power based on some runtime condition or at a specific clock cycle of computation.
But the certification agencies (and real attackers) had.
Once we got a complaint from a cert agency that a specific pattern on the oscilloscope would leak information.
They claimed that the pattern corresponds to a specific part of the OS code.
Using the oscilloscope I was able to disprove that statement.
I just added code that created spikes at specific locations in the OS code.
Then running the request the oscilloscope proved that the pattern of the complaint belonged to a totally different part of the OS code.
Now how to generate a "spike"?
That was easy -- just power on the (hardware) random generator and immediately power it off with the next command.
But that was long ago, before IBM sold its smartcard business and I joined DataPower development 4.5 years ago.
The last posting showed how to process quoted-printable encoded root section of a multipart/signed message by a simple transformation with service chaining.
* need to decode a quote-printable string
* do not like service chaining
* do not like to have a seperate WTX binary transform action with QUOTEDTOTEXT() function
then the single stylesheet solution posted here may be what you want to try out:
Attached to that posting is a correctly formatted multipart/signed sample message (with CRLFs) and the stylesheet.
This sytelsheet is a nice demonstration of these features:
* accessing Non-XML input
* UTF-8 validate input (needed for safety, OK for scenario since ASCII is a subset of UTF-8)
* having a func:function doing some preparation work (eliminate soft line breaks, split at '=3D')
* having a recursive func:function doing the rest.
Important for the recursive function is doing only what needs to be done in the stylesheet and rely on efficient extension functions (regexp:replace) where possible.
Last, but not least, it demonstartes how you can map a unicode code point to a parsed charecter entity inside a stylesheet by mapping (for ISO-8859-1 sample).
HermannSW 2700006U54 Etiquetas:  coproc2 xslt function recursive sum datapower 2.0 xs:decimal 6.156 vistas
XSLT 2.0 data type xs:decimal is available on DataPower:
By the XPath 2.0 spec xs:decimal has to be applied to an atomic type:
* xs:decimal($arg as xs:anyAtomicType?) as xs:decimal?
If you need to apply xs:decimal() to a node-set you may want to use recursive function func:sum() from this stylesheet martins.xsl:
Be aware that xs:decimal does not work without "XSLT 2.0" being selected in Compile options policy of the XML manager:
With "XSLT 2.0" being selected in Compile options policy of the XML manager (here for coproc2 service, or for your service) everything is fine: