Cart
|
[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 XMLlangua
 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@l... > subscribe: xml-dev-subscribe@l... > List archive: http://lists.xml.org/archives/xml-dev/ > List Guidelines: http://www.oasis-open.org/maillists/guidelines.php > 
[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! 
Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|
|||||||||
