RE: [xml-dev] Streaming XML (WAS: More on taming SAX (was Re: [xml-dev] ANN: Amara XML Toolkit 0.9.0))

["Michael Rys" <mrys@microsoft.com>]

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

Both XSLT and XQuery are declarative. The FLWOR in XQuery is not a loop
but a declarative iterator like the SELECT/FROM/WHERE in SQL or the
apply in CM LISP.

The main advantages of declarative languages are that you need to write
less code for achieving a given function point, you operate on a large
set of data at once, and that an execution engine can apply rewrites (if
they are based on an algebra) and other optimizations to execute it more
efficiently.

Procedural languages are much harder to optimize due to their often
lower expressivness at the operator level, their one-item at a time
processing model, and their tendency to allow and sometimes encourage
programming by side-effect.

Furthermore, declarative languages are less brittle towards changes in
the physical design than APIs are. For example, an implementation that
uses a push-parser and wants to move to a pull-based model has to
completely change at the programming level, whereas a program using a
declarative language does not notice any changes below.

XMLReader/TRAX/SAX etc are APIs that mostly promote a one item at a time
processing model and are embedded in mainly procedural languages.
XQuery/XSLT and at least the XPath parts of the different APIs are
declarative.

Is there a place for both? Yes. Declarative languages often come with
extensive support frameworks for the optimizers which may be overkill in
a situation where small, hardcoded logic is needed. And you need them to
build the declarative processing engines :-). But in general I have to
agree with Dana that good XSLT and XQuery engines (or other higher
abstractions) OVER TIME should offer enough benefit of scale,
performance and ease of use, that the majority of implementers do not
need to revert to the lower-level APIs. 

Note that this does not preclude that such engines will need
optimization hints (e.g., to achieve 10% better streaming performance),
physical design decisions etc.; or that one context decides to implement
a predictable subset (see Arpan's posting).

Best regards
Michael

PS: One of the big short-comings of hierarchical databases was that they
basically offered only navigational APIs and were brittle towards
physical optimizations and schema changes. XML is often compared to
hierarchical databases (in the negative sense), but these people don't
realize that declarative languages such as XQuery or XSLT and the
ability to choose different physical designs and optimizations
(including streams) without impacting the logical level make it much
better than hierarchical databases and much closer to so-called
non-first-normal-form (or NF2) models...

> -----Original Message-----
> From: Alan Gutierrez [mailto:alan-xml-dev@engrm.com] 
> Sent: Tuesday, December 28, 2004 4:54 AM
> To: Oleg Tkachenko
> Cc: Michael Champion; XML Developers List
> Subject: Re: [xml-dev] Streaming XML (WAS: More on taming SAX 
> (was Re: [xml-dev] ANN: Amara XML Toolkit 0.9.0))
> 
> * 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
> 
> -----------------------------------------------------------------
> The xml-dev list is sponsored by XML.org 
> <http://www.xml.org>, an initiative of OASIS 
> <http://www.oasis-open.org>
> 
> The list archives are at http://lists.xml.org/archives/xml-dev/
> 
> To subscribe or unsubscribe from this list use the subscription
> manager: <http://www.oasis-open.org/mlmanage/index.php>
> 
>