OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index]
Re: [xml-dev] Feasibility of "do all application coding in the XMLlanguages"?


In my Flower project (temporarily off-line but it'll be back)
I explored a "third way" relative to what you are talking 

XQuery and XSLT should remain purely functional (aka

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


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]

News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 1993-2007 XML.org. This site is hosted by OASIS