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

[Thomas Lord <lord@emf.net>]

On Wed, 2008-12-03 at 15:00 -0500, Robert Koberg wrote:
> 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.


The XQuery implementation <i>should</i> 
only call your resolver once per URI, which
makes it awkward to use that technique in
many situations.

There's no good way to sequence side-effecting
operations that way (not portably).

If your magic URI side-effects a database
that XQuery is looking at, changing data
the XQuery processor has already seen, 
the side effects <i>should not</i> be visible
to the XQuery program.

-t








> 
> -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.
> >>
> >>
> >>
> >
> 
> 
> _______________________________________________________________________
> 
> XML-DEV is a publicly archived, unmoderated list hosted by OASIS
> to support XML implementation and development. To minimize
> spam in the archives, you must subscribe before posting.
> 
> [Un]Subscribe/change address: http://www.oasis-open.org/mlmanage/
> Or unsubscribe: xml-dev-unsubscribe@lists.xml.org
> subscribe: xml-dev-subscribe@lists.xml.org
> List archive: http://lists.xml.org/archives/xml-dev/
> List Guidelines: http://www.oasis-open.org/maillists/guidelines.php
>