[XQuery Talk Mailing List Archive Home] [By Date] [By Thread] [By Subject] [By Author] [Recent Entries] [Reply To This Message]

[Announce] XQilla version 1.1.0 released

Andrew Welch andrew.j.welch at gmail.com
Tue Sep 4 12:29:38 PDT 2007


  [Announce] XQilla version 1.1.0 released
On 9/4/07, John Snelson <http://x-query.com/mailman/listinfo/talk> wrote:
> Andrew Welch wrote:
> >  - Does XQuilla perform XQuery Update to files on the filesystem (does
> > it have transaction support, eg a history of updates?) If it is on the
> > filesystem what sort of use cases do you imagine... I can think of a
> > few but imagine the wrong query could do a lot of damage without an
> > undo facility...
>
> XQilla will save changes to documents back to the filesystem. I agree
> that you could cause a lot of damage, but no more so than a bad use of
> "sed" or any other command line file manipulation tool. The XQilla
> command line tool requires a switch to be specified before it will parse
> XQuery Update - so you won't be able to run an updating expression by
> accident.
>
> If you are worried about overwriting the original document, you can
> always use a "transform" expression and still work with the update paradigm:
>
> http://www.w3.org/TR/xquery-update-10/#id-transform
>
> I think that XQuery Update will find a lot of use cases where XSLT would
> have been used before - I'm sure many people will find the update
> paradigm easier to work with than the transform one for simple document
> modifications.

Thanks.  I'm more an XSLT'er and although I do code XQuery I tend to
find myself choosing XSLT for most tasks.

I think the killer app will be XSLT on XML databases, where the XSLT
controls the "query" (rather than the current way where an extension
applies the XSLT to each result tuple).  XSLT is much better at
processing document centric XML, and generating complex reports
through grouping/sorting, but obviously doesn't scale to 1000's of XML
documents.

You can sort-of do it now on the filesystem using Saxon:

http://ajwelch.blogspot.com/2006/11/using-collection-and-saxondiscard.html

Or using eXists REST interface:

http://ajwelch.blogspot.com/2007/07/combining-xslt-20s-grouping-with-exist.html

The Saxon technique is good for processing directories of XML, while
the eXist technique is faster but requires more setup.

It would great if you could combine of the two languages by embedding
the XQuery in the XML such as:

<xsl:variable name="resultSet" select="xquery('
  for $x in (my xml db) return ...
')"/>

or keep it separate but still execute it from the XSLT eg:

<xsl:variable name="xqy" select="doc('myxquery.xqy')"/>
<xsl:variable name"resultSet" select="xquery($xqy)"/>

and then apply you transform to the whole result set using:

<xsl:apply-templates select="$resultSet"/>

The key point here is that the XSLT has access to whole result set,
not just each tuple, so that it can use its powerful grouping
facilities over the whole set.  You use XQuery to construct the result
set, and XSLT to process it.

Anyway, sorry for highjacking the thread a little there, just sounding
out an idea.

-- 
Andrew Welch
http://andrewjwelch.com
Kernow: http://kernowforsaxon.sf.net/


PURCHASE STYLUS STUDIO ONLINE TODAY!

Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!

Buy Stylus Studio Now

Cast Your Vote

We need your help – Vote for DataDirect XML Products!

  • Best SOA or XML site

Winners and finalists announced at SOA World Conference in November.

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
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-2007 All Rights Reserved.