Hi Alain,
I think we were "lost in translation", meaning that terminology between
you and us got mixed and we got confused. Let me try to distill from
what I understand so far from your two mails:
A. Some legacy system that accepts data in a fixed-width format
B. You want the XSLT to create the full fixed-width format
C. One of the fields "looks like" XML, and, seen as one field, should
be correct XML
D. You have to fill out each field until a certain length
E. You seem to have a preference for Xalan-C (but the above is *much*
easier with Saxon 8.9!!!)
Your question then was about C above. Consider point E and discuss it
please, because you will save for this project and perhaps projects to
come hundredths of hours of coding if you can use XSLT 2.0. For
instance, making the records fixed length is as easy as 1-2-3 (where you
would need recursive templates in XSLT 1.0)
Not sure if you mean if this is already dropped by your team. Anyway,
like the suggestion I wrote, it is not that hard to change an XML
fragment to text.
Another suggestion if you do want to use XSLT 2.0 eventually: you can
code it also as this:
1. First transformation: save HTML to a temporary file
2. Second transformation, all the fields as you normally would
3. When the HTML field passes by, use unparsed-text(...temp file
here...) to include the textized HTML data
Now you can have real HTML or XHTML instead of just XML and you don't
need to write your own 'serializer' anymore.
Cheers,
-- Abel Braaksma
PS: I don't agree that XSLT is hard to use with any ancient legacy
system. Our main interface writes data using XSLT 2.0 to many typical
legacy systems, including fixed width. Agreed, they don't have XML (but
what would a legacy system that does not know XML do with it anyway?)
but as I see it, XSLT comes in very handy when creating specialized
text-based data formats.
Alain wrote:
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.
--~------------------------------------------------------------------
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
To unsubscribe, go to: http://lists.mulberrytech.com/xsl-list/
or e-mail: <mailto:xsl-list-unsubscribe(_at_)lists(_dot_)mulberrytech(_dot_)com>
--~--
--~------------------------------------------------------------------
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
To unsubscribe, go to: http://lists.mulberrytech.com/xsl-list/
or e-mail: <mailto:xsl-list-unsubscribe(_at_)lists(_dot_)mulberrytech(_dot_)com>
--~--