Thanks for writing up the challenges with such a rewrite. Some more
> Few negative/tricky points on doing this:
> 1) This way XML document becomes hard to read: It was a requirement,
> so that the user can go through a generated XML file and build up
> his own Style sheet.
I think the Transformer can be tuned to pretty print the document. For
example, this code makes it output XML that looks more or less
identical to the manually formatted XML generated by the exporter:
(I'm not sure exactly how portable the above code is, but I'm sure we
can work out something that'll do the trick.)
I've also noticed that, no matter how badly formatted the XML document
is, it looks nice and tidy when I open it in Firefox. I assume other
XML tools will behave similarly.
> 2) This need some re-factoring of the design approach:
I agree. It will be a chunk of work that someone must volunteer to do.
> 3) Given the time constraint at that time, I was unable to find any
> other approach of creating the HTML file. Since creating the HTML
> file involves parsing the style sheet as well. I think we need some
> extra classes when creating the XML document. So, I am not quite
> sure about the presence of those extra classes in all JREs.
I'm assuming the JREs in question are the Java ME ones. Those JREs
don't even have the classes used in the generation of HTML files, so
they'd need the Xalan jars on the classpath to be able to run the plan
exporter in any case. I believe the Xalan jars contain all the classes
and interfaces needed, also to generate the XML file, but I may be
> 4) Element.setTextContent() method is not there in J2SE 1.4.2, and
> it gave rubbish when I used setNodeValue().
Right, to make it work in 1.4.2, I think we need to replace
setTextContent(text) with appendChild(doc.createTextNode(text)).
> After considering all these facts I think it's better to keep XML
> generation in this way and just handle those special character
Well, I lean towards the opposite conclusion...
If we had used the XML libraries to generate the XML, we wouldn't have
had this bug or
DERBY-4902, and perhaps other bugs that we haven't
But I think the current patch would be a good incremental
improvement. I'll check it in and back-port it to the 10.7 branch so
that it makes it into the next release candidate. If we want to change
how the XML is generated, we can file a new JIRA issue to track that