[
Lists Home |
Date Index |
Thread Index
]
* Daniela Florescu <dflorescu@mac.com> [2004-12-27 21:31]:
> > Java is not assembler.
> I agree, Java over SAX or STAX is not assembler, as far I am
> concerned it's worse then assembler :-) At least assembler had
> some beauty, and you could really write astute programs with it.
> Remark it is not the Java that I have problems with, it's simply
> the combination Java over SAX or STAX. It's a high level language
> over a too low level (i.e bit-level) API, it makes no sense
> architecturally to me.
> Of course Java over SAX or STAX is a good way to implement XQuery
> or XSLT runtimes, but not to write end applications for XML
> information processing.
It's a good way to implement a parser.
Have you seriously considered the "end application" that I've
described to you? Have you seriously considered what I'm trying
to accomplish? I am coming at XML as a cheap parser.
> I guess we'll have to agree to disagree and move on. If you like
> to write (and rewrite :-) applications like this for fun, I guess
> I'm not gone be able to convince you, right ? :-)
It is the wrong tool for the job. It would only make my job more
complex. I'm using SAX as a langauge parser.
I'm not doing "information processing". I'm parsing a language.
I want a stream of lexemes, with an implied tree structure, to
drive the construction of an AST.
In this case, I am saving an enormous amount of time by using an
existing grammar, XML, and XML Schema for validation, and SAX
for parsing, and my own library to maintain a parse state.
If I were in the rewriting mood, I'd break out JavaCC and design
a Java dynamic invocation langauge. I'm not. I'm using an
existing parser. Gonzo reuse.
It's not a choice of SAX, XQuery, or XSLT, its a choice of SAX,
DOM, JavaCC, or ANTLR.
> >XSLT can be mind-boggling complex.
> Did you try XQuery ? I strongly encourage you to try at least one
> of those higher level XML processing languages; you might
> appreciate the advantages. And if you think they don't solve your
> problem, I would like to understand more about your problem and
> why weren't they good enough.
Not applicable. They are not applicable. It's not a matter of
good enough. It's not an issue of performance. It is an issue of
the programming task. Not applicate. I'll say it again.
I am way cool with XSLT. It is swell.
It can be complex. The OP was saying that XSLT can be convoluted
if it is applied to the wrong task. I'm making the point that
XSLT is a complex functional programming language. It is not an
invariably simplier solution to any programing task that has the
letters L, M, and W, or maybe, X involved.
I've said now, any number of times, why XQuery and XSLT are not
applicable.
They are not in my problem space. I need no more processing once
I get my events. There is no need for me to extract the
information out of order. I am doing stream processing, pure
stream processing, because my application calls for pure stream
processing. XML is the solution I chose for stream processing, I
did not choose stream processing for some arbitrary XML
programing task.
How would I employ XSLT to assemble and Abstract Syntax Tree
that represents a *graph* of Java method invocations? What would
the XSLT emit? A Java class file that I'd then compile?
If all I would do is call a Java function for every element
matched by the XSLT transform, what has XSLT or XQuery bought me?
Writing dozens of external Java methods, maintianing a mindless
XLST script that calls each one, and then, I'd have to somehow
convey to the Java method the current state of the parse. I've
gone backwards, or rather, the information I need is lost in the
abstraction you are proposing, I have to reconstruct it.
Not good enough is not my issue. Not applicable is my issue.
The solution you provided, where all XQuery does is call a
function...
How is that better than SAX? You offered, what, easier to make
changes? In what way? Change grammar, change matching, change
code, verus change grammar, change strategy composition, change code.
I've now answered your question in detail. Does this help your
understanding?
--
Alan Gutierrez - alan@engrm.com
|
