Bugreport

[jo...@post.RWTH-Aachen.DE]

Hello people!

This is my first bugreport, and though I'm quite sure it really is one, 
and I've downloaded XALAN recently, I'm not complete up-to-date.

I'm using XALAN in an Email -> XML archiving project, to get a hand on
(and prettyprint :) the results. One of the problems I have concerns the newlines
in the data. I've compiled it for Windows with Visual C++, but just because I haven't got 
the nerves to get the Makefiles running for my DevCpp, which I use for my projects 
(actually I don't really use the IDE, only the binaries from the shell, sometimes using VC 
as the editor, though this is probably the greatest waste of ressources possible, but 
VC's editor _is_ good (sometimes)). 

I want XALAN not just to produce HTML, but valid and usable JavaScript as well,
in fact, I want to pipe all data through one of the two JacaScript decoding functions:
"unescape" and "atob", which is implemented by Netscape only, to my knowledge. This 
of course depends on the way the data has been encoded.

To handle the newlines, I've tried to escape the '\n' to %0a, and this actually works 
inside a "pre"-tag. But I don't like this solution, because, the XML-data, is the not very 
readable.
But, doing it this way, I can call "normalize-space" on the data and produce a valid
JavaScript string like this.

var buf = '<xsl:value-of select="normalize-space(./contentdata)">';

This is, of course, equally less readable in HTML, if it's much data, but the browsers get 
it right,
though the editors not :)
Do see this way, follow the way the data from the second "contentdata"-element in 
bug.xml takes.

Now, how to produce a valid JavaScript string, if you have not escaped the '\n'-chars when
producing the data?

1. You still call "normilize-space". all newlines are gone, and all gets scrambled up, but 
it's fast.

2. You find a way to unfold the string into the single lines. Thus producing even a nice
readable output like this.

var buf = 'dfsfd' 
	+ 'sdfafd dasdf dfradff'
	+ 'sdfafd dasdf dfradff';

I've done this by writing the recusive template "split", which you find in bug.xsl. This 
template is very ineffective, though. I believe it's because it's recursive, but I find no way 
to write it iteratively (right?). But recursion is something that "is in the air" programming 
stylesheets, so you should have a look at this when you've got some time spare. 
When I want to unfold something like an attached image into single lines, after 10 
minutes of work, I get a prompt my diskspace was used up, which is because of the 
swapfile. I'm using Windows98 on a 300 Mhz Pentium with 128 MB of memory and 
about 300 - 400 MB free space on drive C (where the swapfile is), while the 
XML was about 3 MB, so you see the problem.

Well, now to the actual bug I've encountered:

This is the output I get when running (the param stuff does not matter)
D:\src\mf>testxslt -in bug.xml -xsl bug.xsl -out bug.html -Param Restore_nl 'y'

========= Parsing bug.xsl ==========

XalanDOMException caught.  The code is 3.


Replacing the <xsl:choose> .. stuff in bug.xsl by the IMO completely equivalent code 
with the <xsl:if> you'll find there encommented, get's me this:

D:\src\mf>testxslt -in bug.xml -xsl bug.xsl -out bug.html -Param Restore_nl 'y'
========= Parsing bug.xsl ==========
Parse of bug.xsl took 60 milliseconds
========= Parsing bug.xml ==========
Parse of bug.xml took 50 milliseconds
=============================
Transforming...

transform took 0 milliseconds

Total time took 50 milliseconds


I cant find a reason for this, since I've copied the code from the if-part
to the choose-part with cut/paste, to be sure it's the same.

Thank you for reading this. 
email me at j-willkomm@web.de.
If you like, have a look at my TestXSLT frontend for Windows at
http://www-users.rwth-aachen.de/johannes.willkomm/projects.html