Re: [xml-dev] Feasibility of "do all application coding in the XMLlangua

[Thomas Lord <lord@emf.net>]

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