Tool development: by Perl-wrapped XQuery

[Michael Ludwig]

David A. Lee schrieb:
>> 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?
>>
> In my opinion the problem with doing this in perl is that unless the
> xquery implementation itself is in perl or atleast runs within the
> same process you will run into horrible performance problems.

Of course. JVM invocation overhead, IPC overhead. No persistent process
supported by indexes to speed up queries, all possible optimizations
forfeited. But Hans-Jürgen's approach is convenient and sufficient where
performance is not paramount.

In Perl, reasonable XQuery integration can currently be achieved by
using Oracle Berkeley DB XML. Of course, while the interface is in Perl,
the implementation is in C++.

If there were Perl bindings for XQilla XQuery in Perl would be possible
within the process but without the Berkeley database.

But the main speed factor for XQuery is simply the indexes available in
the database. How could it be otherwise? So you need a server process
built on indexes. That's usually C/C++ or Java, like most servers;
scripting APIs are a nice extra.

An alternative is to have some persistent XQuery process running and
having Perl/PHP/Python processes interface to it via HTTP/REST/WHATEVER.

> * Use a scripting language that already is 'in process' with all the
> XML core languages you want to use (xquery, xslt etc)
>  -> examples XProc, xmlsh
>
> * Encourage scripting languages developers to embed these XML
> languages directly into the scripting languages (say perl).

More precisely, write bindings to implementations in C/C++.

-- 
Michael Ludwig