Cart
|
[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: Feasibility of "do all application coding in the XMLlangua
 Kurt, In my Flower project (temporarily off-line but it'll be back) I explored a "third way" relative to what you are talking about. XQuery and XSLT should remain purely functional (aka declarative). Non-standard "extension functions" should be avoided almost always, for at the very least the break portability. Commonly, extension functions are poorly designed in that they sneak in non-declarative, sequencing semantics. Pipelines (e.g. XProc) aren't flexible enough regarding side effects and flow of control. For example, in most pipeline systems, you can't do recursion. Instead, I invented a kind of "I/O monad" for running XQuery and XSLT scripts in a kind of continuation passing style. A computation (say, in XQuery) returns a list of side-effecting operations to perform plus a continuation. The continuation is itself a second XQuery script. The monad performs the side-effecting operations, packages up the results as XML Datums, and invokes the continuation. Repeat in a loop until eventually a "null" continuation is returned. If you want to add, say, an FFT function -- don't bind it into XQuery as an extension function (thereby dragging in hundreds of thousands of lines of code including a complete graph-tracing GC where less than 10K lines of code are needed). Rather, package the FFT in a web service API: the I/O Monad calls out to it and then resumes XQuerying. The FFT engine can be same-process or could be remote -- only performance will differ. It's then desirable to create syntactic abstraction mechanisms over XQuery.... -t On Wed, 2008-12-03 at 11:08 -0800, Kurt Cagle wrote: > > > 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. > > > 
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] |
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! 
Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|
|||||||||
