Tool development: by Perl-wrapped XQuery

[John Snelson]

Hans-Juergen Rennau wrote:
> As Daniela Florescu emphasized, XQuery is an information processing language, rather than a query language, and this makes it a great implementation language for tool development. But two problems discourage the use of "raw queries" - without frontent or wrapping of any sort - as tools:
> 
> a) no default parameters
> b) no standard-based access to system commands, namely no file discovery

I think that these are very good examples of functions that need to be 
added to EXPath.

> a) is in conflict with the requirement of powerful tools to offer a great number of options; and b) forces the caller to specifiy all input files - possibly hundreds or more - explicitly. (Or to provide secondary input files containing the file names, making things complicated..)
> 
> So David A. Lee recently wrote:
> "I had to write a bunch of "framework" code in Java just to arrange to *call* xquery ( you know, find the input files, get the xquery files, setup the parameters, call it, serialize the results etc)."
> 
> David's contribution drew my attention to xmlsh which seems to me a fascinating approach. But I feel that (at least presently) tool development per XQuery needs a lightweight approach to wrapping. (No?) I have taken to an extremely simple technique of wrapping queries in Perl, thus overcoming the problems mentioned above: 
> 
> a) get the powerful command line interface of Perl scripts (options and arguments, defaulting)
> b) leave the preliminary file discovery to Perl (e.g. per glob)
> 
> The queries themselves I insert as here documents right into the Perl code, one function per query, like this:
> 
> sub xq_foo {       
>     return << 'EOF';
> (: here comes query 'foo', possibly thousands of lines ...  :)
> EOF
> }
> 
> This is significant for keeping things simple: one Perl script can infact be a library with dozens of queries of unlimited complexity. (This way the tool software can be structured into a small number of deliverables each of which is a whole application, rather than a script in the conventional sense.) The approach is rounded off by letting Perl select the query, construct the command line invocation of your XQuery processor (e.g. Saxon), calling the processor and returning the output on stdout. Having written a couple of such Perl-XQuery-hybrids you recognize a uniform pattern of how to organize this little translation of Perl input into XQuery invocation, including input checks, so that from the third specimen onwards you have, in terms of effort, virtually no overhead, just write query after query INTO your Perl frame, and add invocation branch after invocation branch.
> 
> Now my questions: 
> - would you recommend alternatives for rapid tool development?

I can't fault what you're doing right now - but it would be nice to be 
able to handle this in pure XQuery.

> - if taking a similar approach - would you like to recommend special details, perhaps the script language actually used, or other aspect?

I think that pure functional XQuery is always going to have issues with 
tool writing, since it believes that the world doesn't change during the 
time a query is executed (and goes to great lengths to make this seem 
so). This is clearly a good use case for XQuery Scripting Extensions, 
which introduces a notion of time passing and the world changing whilst 
still remaining largely functional.

http://www.w3.org/TR/xquery-sx-10/

John

-- 
John Snelson, Oracle Corporation            http://snelson.org.uk/john
Berkeley DB XML:            http://oracle.com/database/berkeley-db/xml
XQilla:                                  http://xqilla.sourceforge.net