Subject: [xsl] Re: XML/XHTML fragment to text From: Alain <alainb06@xxxxxxx> Date: Tue, 14 Aug 2007 13:19:29 +0200 |
E. You seem to have a preference for Xalan-C (but the above is *much*easier with Saxon 8.9!!!)
But at work, the only thing that has been authorized for now is Xalan-C. It is running in batches (jobs) on AIX machines. The reason why they are not considering another transformation engine, at the moment, is performance. Even for a small transformation if you run Saxon or Xalan-J, you will have to set up an run a JVM in your Unix batch. Launching the JVM has a cost in memory and time. And even if you don't count the JVM cost, Saxon is Java code, so it has to pay the Java overload compared to a code written in C++... Although Saxon may perform faster on some specific templates where it has better optimisations, on an "average" template it will still be slower because it's Java versus C++. The goal is to be able to run a 5 million base customer, so we have to count every second in our batch process.
But things might change a little bit now. Because for SEPA (Single Euro Payments Area) they choosed to write a Java program and run it in our main batch to transform the XML (ISO 20022 defined) files to fixed-length format understandable by our legacy Cobol programs. So they are definitely running a JVM inside main the batch, and I will point that to the persons in charge of choosing standard software. The cost of maintaining a Java program for such a transformation might also be higher than having just a XSL stylesheet where possible (I'm not on the SEPA project so I didn't look if it is possible to transform the ISO 20022 XML easily).
For instance, making the records fixed length is as easy as 1-2-3 (where you would need recursive templates in XSLT 1.0)
3. When the HTML field passes by, use unparsed-text(...temp filehere...) to include the textized HTML data
I didn't use this function yet, it looks as a very elegant way to solve the problem, except for one little thing (but I'll check the documentation).
The last bit of headache is the "UTF-8" problem ! Because fixed-length is fixed-length in *bytes*. It is fine with ISO8859-1 where char=byte. But as we run internationally and also have Greece, Russia, etc... and could run in China, we need UTF-8.
For that, with XSLT1.0, I agree with you, I had to build insane recursive templates to calculate the length in bytes of an UTF-8 string. It's so insane, I tend to think at this point we would rather write a Java or even Cobol program. With XSLT2.0 it's easier, but still difficult because you are doing things only the serializer should do... or is there a function I didn't notice that can return a string length in bytes and not in chars ?
Not sure if you mean if this is already dropped by your team.
Current Thread |
---|
|
<- Previous | Index | Next -> |
---|---|---|
Re: [xsl] Re: XML/XHTML fragment to, Abel Braaksma | Thread | Re: [xsl] Re: XML/XHTML fragment to, Alain |
Re: [xsl] Merging Two Nodesets .. c, Mukul Gandhi | Date | Re: [xsl] Problem with xsl:number f, bryan rasmussen |
Month |