[xsl] Re: XML/XHTML fragment to text
Subject: [xsl] Re: XML/XHTML fragment to text
From: Alain <alainb06@xxxxxxx>
Date: Mon, 13 Aug 2007 10:02:36 +0200
|
Thanks for your advices, they have been very helpful.
Let me elaborate a bit. When I wrote text output for a legacy
application, I was implying fixed format text.
Variable text would have been as easy as any other output, I agree with
that.
The output looks likes :
@@@ 123456701/08/2007<div>Any XML/XHTML</div> (..many
spaces..) {other data+other records}
Specified as (for every record):
Offset
1 (length 3) @@@ // Fix banner 3 characters @
4 (l = 7) filler // blank filler (future use)
11 (l=7) Customer-ID
18 (l=8) Start date, format DD/MM/YY
26 (l=150) HTML fragment
176 (l=8) Other data
...
Legacy systems love this sort of fixed stuff because they can just feed
it to a Cobol Copy and play with it.
So you see, it's definitely <output method="text"/> because the output
is not at all some valid XML.
I would be glad to be able to do some thing like :
<output method="text"/>
<!-- Some code for my text output -->
<xsl:copy-of method="html" select="fragment" />
<!-- more code for text output -->
That would be OK for what I have to output, but there will still be a
problem.
I have to know the exact number of byte that have been output so that I
can pad the html zone to the right length.
Therefore I have to sort of "cast" the nodeset to a string.
So that's why I wrote trying to use XSL for 3rd generation legacy
programs is quite unnatural and not so easy.
Anyway, they must have guess the initial design is not right. The
decision seems to be to separate the XHTML and the fixed output.
The XHTML will be put alone in a single file (and then it will be safe
to use a copy-of and HTML method) and we will output the
name of the file in the fixed structure.
There will then be another performance issue: if we have a million
records there will be a million small files to be handled by the
filesystem... but that's not an XSL issue anymore !
Thanks again.