[xquery-talk] [Announce] XQilla version 1.1.0 released
andrew.j.welch at gmail.com
Tue Sep 4 12:29:38 PDT 2007
On 9/4/07, John Snelson <john.snelson at oracle.com> 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
> If you are worried about overwriting the original document, you can
> always use a "transform" expression and still work with the update paradigm:
> 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
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
You can sort-of do it now on the filesystem using Saxon:
Or using eXists REST interface:
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:
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.
More information about the talk