> > yea, but a lot of people are using it like PHP rather than a replacement
> for
> > SQL on XML. It is the way XML DB vendors recommend you make webapps.
> > Writers/editors (at least the ones I have been reading) seem to think
> this
> > is the way to go. It seems like a step backwards.
>

Not sure I'd completely agree with that (of course I'm one of the
writer/editors that's been advocating this approach). If XQuery+extensions
was purely declarative, then the filter approach works fine, but in point of
fact one of the most significant changes taking place in the XQuery space is
the introduction of database modifying code. Once that happens, then
realistically you do have to think about XQuery as being at a minimum part
of a processing pipeline and quite possibly the only part of that pipeline
This changes the dynamic for XQuery pretty dramatically, and moreover it
does so by reducing the processing of a servlet into a complete XML
environment.

However, the key here is again to keep the XQuery as simple (and
standardized) as possible - There's an interesting recurrent Filter -> Sort
-> Partition (Page) -> Style pattern that seems to show up over and over
again in the XQuery I work with, for instance, and XQuery works remarkably
well when you deliberately keep your systems as RESTful as possible.

Is that the only use for XQuery? No, of course not, but from a web
development standpoint it is a primary pattern. Like everything else, it
works best when you avoid inlining XQuery and XML markup (one reason that
PHP, or most server-side code constructs, can be such a pain), but that's a
lesson that only seems learned by experience.