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