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