Cart
[Home] [By Thread] [By Date] [Recent Entries]
> > > 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. Sure, that will be nice. > > > 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. You had me at Filter (and maybe Sort). I might be conflating Filter and Partition -- what is the difference? I don't want Style in XQuery. Use XQuery to just gather up the things wanted and needed. That is why I think XSL running natively on the XML DB is important. Don't convert the XQuery result into a Source needed by an XSL processor on top of the DB, just continue on with the XQuery result. -Rob
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] |
