Xalan-c and DOM

[Jon Smirl <jo...@mediaone.net>]

From: <Da...@lotus.com>
> Did you include PlatformSupport.lib in your link line?

I figured out that I had edited the DOMStringHelper.h file a few days ago
and added the third parameter in order to make my code compile. I've altered
the code now to support indexOf with a startOffset. I can send you the code
if want, it's a trivial change to do.

> Please switch your code over to using the Xerces DOM APIs.  If there is
> something missing that keeps you from doing this, let me know and I'll try
> to provide it.

I need to be able to feed the output of one Xalan stage into another Xalan
stage. I was planning on doing this via FormatterToDOM. I also optionally
use Javascript to manipulate the trees in between stages so I was building a
Javascript accessor wrapper around the XalanDOM model.  In my XT based Java
code I wire the two XSL stages straight together with SAX unless there is
Javascript present that forces the DOM to be built. I could probably
eliminate this Javascript when I get an XSLT engine which supports
Javascript extension elements. I'd just move the code into the first stage's
stylesheet.

I liked using the Xalan DOM because it isolated me from Xerces and
DOMString. Wasn't Xalan designed to allow plugging in different parsers and
string types? There are three basic string types defined in XalanDOMString.
I had thought that my code would automatically adjust just by changing the
defines (I hadn't tried yet). By using the XalanDOM I thought it would make
changing the parser and parser's DOM transparent to me.

I'm also using just about every function in DOMStringHelper. Anyone porting
Java code is going to need all of these.

Some questions that come to mind...
1) Should Xalan maintain parser independence or should it just be merged
with Xerces like MSXML3?
2) Should all of DOMStringHelper be pushed back into Xerces?
3) Should Xalan only take SAX/2 events as it's input and output and then
come via a support lib containing things like the formatters and
DOMTreeToSAX and SAXtoDOMTree?
4) Should Xalan provide a complete mutable DOM wrapper? The only thing I do
with the DOM tree I build is feed to Xalan as input, shouldn't I just make a
Xalan compatible tree to begin with.
5) If Xalan hides it's DOM support, how is FormatterToDOM going to work,
which DOM will it use?
6) In James Clark's code the DOM support is in XT (the XSL Processor) no XP
(the parser). Should the DOM support be moved out of Xerces and into Xalan?

Maybe the answer is three libraries not two.
1) XML parser generating SAX events
2) XLST processor with SAX in/out
3) Libraries for converting from/to SAX into DOM trees, HTML, XML, etc. For
example, I contributed a driver to FOP that takes the output SAX events from
XT and directly builds the internal FOP objects which have nothing to do
with a DOMTree. The library would also have string support with transcoding
and Java string compatibility methods.

Besides, I just got my ported app to compile and link today.

Jon Smirl
jonsmirl@mediaone.net