OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help



   Re: [xml-dev] Streaming XML (WAS: More on taming SAX (was Re: [xm

[ 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
    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
    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

Alan Gutierrez - alan@engrm.com


News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 2001 XML.org. This site is hosted by OASIS