Re: Processing XSL from RPGLE

Googling shows hardly anything on the web related to XSLT4C
It appears there has been little interest from the i5 community to the XSL feature of the IBM XML Toolkit. Most relates to the RPG based XML stuff.
I tried installing 5733XT2 options 4 and 5 which provide xmltookit4 samples but this still has the same problem.
Despite the IBM toolkit doco apparently boasting about ICU being fully integrated, this is not the case. ICU appears to be the mechanism by which extended XSL functions like format_number() are implemented.
I did discover that the sample C++ compiles require the DEFINE keyword to also include XALAN_USE_ICU as the IBM provided source code has ICU functionality embedded in the samples is conditioned by this.
But this also requires downloading the include files from Apache that are expected to be found in the ICUBridge folder of the toolkit.
However, after all that, the sample compiles fail to bind since the underlying *srvpgms provided by IBM do not export the expected ICU procedures.
A bit of a dead end.

However, having also just installed Zend Server I find that I can transform xml to html via xsl right out of the box using just a few lines of PHP script.
Yippie.

Peter


-----Original Message-----
From: web400-bounces@xxxxxxxxxxxx [mailto:web400-bounces@xxxxxxxxxxxx] On Behalf Of Thorbjoern Ravn Andersen
Sent: Sunday, 1 May 2011 8:07 p.m.
To: Web Enabling the AS400 / iSeries
Subject: Re: [WEB400] Processing XSL from RPGLE

Den 22/04/11 02.26, Peter Connell skrev:

Hi,

RPGLE now has very useful XML parsing functions built-in, which we use much to our benefit.
But it would be nice if there was functionality to perform XSL transformations without having to build our own utilities.
To achieve this I had to find the java code (not much) to create a custom wrapper class that uses javax.xml.transform etc to transform an XML file using an XSL file into an HTML file.
But the initial JVM load is annoying (without resorting to data queues and such).

However, we've just upgraded to V6R1 and I happened to look at the XML Toolkit and noticed there is XSL support via C++.
I thought this might be worth a look since a compiled C++ routine should give better performance than java (well that's the bet).
I discovered that the installed QXSLDEV110 library has the CLP source for CRTXSLCPP whose text is "CREATES XALAN C++ TEST/SAMPLE PGMS IN GIVEN LIB".
If you compile this then, provided that you also have the ILE C++ compiler installed, you can call this CRTXSLCPP program which then compiles all the necessary C++ programs for you. What a breeze, and without having to know any C++.
Stumbling around the folder of samples in \QIBM\ProdData\xmltoolkit2\xsl_1100\samples, reveals that one of the C++ programs compiled is called TESTXSLT which does just what my existing custom java transform does.
And it seems to work, at least with the simple things I've tried at first.
But, on a mor complex XSL stylesheet, whenever it finds the format-number() function in an XSL stylesheet it throws an annoying message "Warning: The function 'format-number()' is not implemented."
Of course, I don't understand this problem but wondered if anybody might point me in the right direction. ( might have something to do with an ICU thing)

This is very interesting as an alternative to a JVM based solution.
Note that the actual transformation will most likely not be much faster
- and for many transformations in a run the Java facilities for caching
compiled XSLT programs may be much faster - but that it is faster to
start the program itself.

It sounds like this is a ported version of Xalan 1, which is an Apache
project available at http://xml.apache.org/xalan-c/usagepatterns.html.
The mentioning of ICU in relation to missing format-number function does
not sound like it enables the function but more that it becomes fully
locale-aware (does it run or crash?). The cause may be that this is an
old Xalan without a full implementation of the XPath language (which is
the expression-inside-quotes language) - I vaguely recall that this can
be because the XSLT program is precompiled and that implementation is
not complete.

Is anybody using this instead of Java based XSLT?