Better StyleSheet Processing (was: Happy to be wrong!)

[John Milan <jm...@DataChannel.com>]

> This is not to say the performance of
> Xalan is as good as it needs to be yet (though we're making some major
> progress which I hope you'll all see next couple of weeks), but using a
> pool of prebuilt stylesheet will make a major difference, I think.  Direct
> SAX output to the result stream, when appropriate, would also make a major
> difference.

With our proprietary parser :(
we implemented this approach and it did make a big difference,
especially with respect to scaling, as the number of java objects
created went *way* down.

We have not tried direct SAX output to the result stream, but it sounds
good.

In general, flexible manipulation of data streams seems vastly superior
to 'compiled' solutions dedicated to particular formats, in my opinion.
In some ways, I feel like I'm reading a byte-code versus compilation debate
:)

In fact, let's take it that route... 

This statement:

> I believe you can translate any XML document into Java Code...
> Basically you can translate a XML document into a class that generates
> (for example) SAX events...

scares me a bit. Here come the C/C++ code translators, the Perl translators,
the
Python translators, on all different platform combinations, and so on.
Doesn't
this defeat the purpose of having a well-defined text stream like XML? Do
you
want to have to build a framework to support multiple languages, on multiple
platforms? What happened to 'stream once, process anywhere?'

And finally, can we really say we've exhausted the performance of text-based
stream processing? I don't think so.

my $.02

John Milan