|
[XQuery Talk Mailing List Archive Home] [By Date] [By Thread] [By Subject] [By Author] [Recent Entries] [Reply To This Message] Tool development: by Perl-wrapped XQueryHans-Juergen Rennau hrennau at yahoo.deFri Sep 4 00:08:09 PDT 2009
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
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?
- if taking a similar approach - would you like to recommend special details, perhaps the script language actually used, or other aspect?
Any feedback would be highly welcome!
With kind regards,
Hans-Juergen Rennau
|
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
|






