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: [xml-dev]

[ Lists Home | Date Index | Thread Index ]

* Oleg Tkachenko <oleg@tkachenko.com> [2004-12-28 05:40]:
> Michael Champion wrote:
> 
> >I'm not sure how that will ever
> >change; for example, people are still fiddling with their SQL code and
> >table organizations to get optimal performance rather than simply
> >trusting the implementations. Why will that be different for
> >XPath/XQuery?
> 
> I believe Daniela's point is that people shouldn't come up with 
> home-brewed XML processing engines nowadays just as nobody's writing 
> home-brewed database engines anymore. XML processing shouldn't be a 
> matter of art, while it shouldn't perform poorly by default neither.
> 
> Imagine a guy who only wants to rename some elements in an XML document. 
> SAX filter/custom XmlReader is one way to go, 10-lines XSLT stylesheet 
> is another one (and a better one as being declarative).
> The sad thing is that XSLT impementations currently aren't smart enough 
> to realize that such XML transformation can be done in a streaming way, 
> so XSLT way's perf will be definitely worse and XSLT will definitely be 
> the one to blame.

     I'm not one for nattering on listservs, so I can't tell when
     horse is dead, please tell me if I should stop beating.

     Part of this is a debate over declarative versus procedural
     programming. Here one person has made an absolute statement,
     that is backed up by millions in marketing dollars from various
     RDBMS vendors (not a cynical statement, they make fine
     products), in favor of a declarative expression of a task over
     a procedureal expression. Daniela has compared XQuery and XSLT
     to SQL, while SAX and STAX are assembler.

     Except that, XSLT is a functional programming language, and
     from what I can see of XQuery, it has a lot of looping. SQL is
     a declaration of, well not my lexicon, a desired result set in
     the terms of relational calculus.

     Are XSLT and XQuery declarative?

     There no direct conceptual mapping from XQuery to SQL. There is
     no direct conceptual mapping from SAX and STAX to assembler.

     SAX and STAX are not languages. They are application
     programming interfaces.
     
     In my world, Java application programming, I see the choices as
     SAX, STAX, DOM4J, W3C DOM, or TRAX. I am being told to consider
     TRAX my panecea.

     Using TRAX immediately adds adds support issues, such as the
     Xalan inconsistancy, a weak parser shipped with the JDK,
     resource files, and additional langauges.
     
     The idea that my problems are made simplier by implementing my
     program as Java method bindings to an XSLT engine is absurd.
     Now I've committed myself to a particular XSLT implementation,
     TRAX is out the window.

     Java, Python, Perl, XSLT, XQuery. Those are langauges.

     They are all Turing complete. Any algorithm that can be
     expressed in Java can be expressed in XSLT. If what I want to
     express is the construction of a JMenuBar, using XSLT is going
     to be a nightmare.

     Here's what this sounds like to me:

     "Any modern user interface an be expressed using XForms, XML +
        CSS, and SVG, and binding behavior to the DOM Event Model."

     "Therefore, people should abandon direct GDI, PalmOS API, Cocoa,
        or GTK+ programming, abandon Swing, wxWindows, SWT, Qt, and
        pour there energies into writing XForms, XML + CSS, and SVG
        applications, because that will drive the development of
        rendering engines."

     "We simple need to commit to developing these rendering engines,
        and all accept that the declarative UI will reign supreme,
        from handhelds to computer animation."

     "To worry about the performance of your UI is waste of effort.
        The rendering engines will, eventually, know how to optimize
        for any and all problems."

     "Any anyone who wants to pick up a pen and scribble on the
        device context in C is just a dinosaur."
    
     That was meant to sound, ideal, yet rediculous, for the record.

     Thinking harder about streaming libraries, expression of
     streaming problems, and the needs of stream processing is a
     good thing, because, as an concept in data, the stream is not
     going to go away. It is not an ugliness. It is what data does
     on its way from here to there. Perfectly natural.

     Cheers.

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