[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 XML langu

  • From: Robert Koberg <rob@k...>
  • To: xml-dev@l...
  • Date: Wed, 3 Dec 2008 15:00:11 -0500

Re:  Feasibility of "do all application coding in the XML langu
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.
>>
>>
>>
>



[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!

Buy Stylus Studio Now

Download The World's Best XML IDE!

Accelerate XML development with our award-winning XML IDE - Download a free trial today!

Don't miss another message! Subscribe to this list today.
Email
First Name
Last Name
Company
Subscribe in XML format
RSS 2.0
Atom 0.3
 

Stylus Studio has published XML-DEV in RSS and ATOM formats, enabling users to easily subcribe to the list from their preferred news reader application.


Stylus Studio Sponsored Links are added links designed to provide related and additional information to the visitors of this website. they were not included by the author in the initial post. To view the content without the Sponsor Links please click here.

Site Map | Privacy Policy | Terms of Use | Trademarks
Free Stylus Studio XML Training:
W3C Member
Stylus Studio® and DataDirect XQuery ™are products from DataDirect Technologies, is a registered trademark of Progress Software Corporation, in the U.S. and other countries. © 2004-2013 All Rights Reserved.