Could the BaseX developers confirm that this is in fact the only robust way to interact with the database? I'm very surprised by this; to draw a comparison to relational databases, it's as if the only way to interact with the database is through its command line shell, and as if language bindings for SQL had never been invented. Is this, in fact, the state of the art in XML databases?
It's too simple, and imprudent, to equate XML with the relational world. In fact, your use case isn't that obvious for everyone as you might believe. Many users have quite a different approach to XML data, which you'll note if you take the time to browse our archive, and the mailing lists of other XML databases and processors. Just as an example, many users don't require variables bindings as they code everything in XQuery (I've come across an XQuery expression used in product environment, which was 80 KB in size), or will dynamically compose the query which is to be evaluated. In short, there is in fact no single "state of the art" in XML, which will work for everyone – and there will never be just one.
Our objecctive is try to cover as many requirements as possible, and – again – XQJ is just one of them, which isn't requested that frequently as other features. A short while ago, we've asked on the mailing list which missing or incomplete BaseX features are requested most, and I'll soon publish a summary of the results back to list. To be honest, no one asked for better interfaces, which indicated to us that the existing framework seems to cover most requirements, at least for people following our mailing list. And this framework includes not just the command line shell, which you chose to mention, and which is just a frontend user interface, but:
– our language bindings for different programming languages (basex.org/api) – our REST interface, based on JAX-RX – our own API, (either embedded or client/server-based) – XML:DB and XQJ
Next, it is wrong to regard our XQJ implementation as unstable. In fact, some effort has been put into this API, and it covers 100% in the available test suite (it's included in the JSR 225 distribution and in our API package). Feedback like yours might help to make it more robust, though. Adding support for the EventTarget interface might be an interesting extension as well, but it's not a mandatory part of the standard.
After all, what you see and get here is Open Source – and, as your own surely know by yourself, successful open source projects benefit from, and are dependent on, external contributions. We'll soon offer commercial support, which might give you the chance to speed up the development of features you cannot afford to program by your own. As an alternative – which might be more reliable for the moment, but way more expensive as well – you still have the choice to go for one of the commercial alternatives, such as Mark Logic, Data Direct, xDB, etc.
(*) as pointed out earlier, for retrievals, I already have no choice [...]
I tried to point out in this mail that you rather have too many than too less choices; unfortunately, none is just free.
Have fun, Christian