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

[Robert Koberg <rob@koberg.com>]

Hi,

I am curious how you would contrast this to using the doc function and  
a custom URIResolver (in java, which is what I tend to do).

For instance,

doc(check-to-see-what-i-might-need)/*

then loop through those things

doc(some-thing)/*

the URIResolver returns the thing you need without the XSL/XQuery  
knowing anything about what went on to make it happen.

-Rob


On Dec 3, 2008, at 2:33 PM, Thomas Lord wrote:

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