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 ]

* Michael Rys <mrys@microsoft.com> [2004-12-28 18:42]:
> >      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).

    Thank for this response. Illuminating.

    I agree with the conjecture that over time XQuery and XSLT will
    offer benefits in performance and scale. I offered an absurd
    parallel to decarative user interfaces, but one that I don't
    think will sound obsurd ten years from now. The example of the C
    compiler, and compilers in general is the other side of the coin.

    For me, right now, XML is a JavaCC alternative. I'm dealing with
    kilobytes of data here. I'm not reverting to a lower-level API,
    but stepping back to higher one.

    I've said, that the time spent here is not on processing, but on
    the application logic, moving to XQuery buys me nothing. It is
    such that I have to imagine that there are other applications
    where this is so, and that treating XML as a series of events
    might solve other problems. 

    I've asked, sincerely, is there a reasonable way to assemble a
    graph of reflected method calls in Java, using XQuery, and I've
    not been given a compelling answer.

    I'm feeling that there might be an opening for a new langauge
    that maps events to procedural instructions. Is that SOAP? (All
    those boats I missed.) Conceptually, I see XML worm turning a
    procedural gear, a finer mesh than SOAP.
    I'm still wondering if streaming XML is still not an area of
    study, a special domain, that deserves the attention that it
    received in this tread. Over time, XSLT and XQuery, will get
    ever more intellegent, but over time, could we not see an
    exponential growth in the size of XML streams? Probably not
    without that Binary XML thing.

    Maybe streaming XML is a niche, or maybe it's been nichified by
    the exhorations of database vendors, but I don't think that
    streaming concepts are something I personally want to move away
    from. (In fact, the little langange I'm writing configures a an
    XML pipeline engine. So, there!)

    Kind regards.

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