On Sat, Jul 24, 2010 at 8:55 AM, Christian Grün christian.gruen@gmail.com wrote:
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.
I don't care about XQJ as such. 6 months ago I didn't even know it exists. I care about the ability to easily and robustly interact with the database. I need to be able to write maintainable queries that contain placeholders ('variables') where application objects are inserted.
I claim that having this ability is a frequent requirement; or conversely, that applications that use an approach where large XQueries are cobbled together textually and very likely not robust. Take a look at the numerous SQL injection vulnerabilities that resulted from people cobbling together SQL code as just an example of why this approach is fragile.
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
On basex.org/api there are links to the language bindings, which also seems entirely text-based. (For instance, https://svn.uni-konstanz.de/dbis/basex/trunk/api/etc/java/QueryExample.java )
Do you have documentation for your embedded or client-server based API?
Does it support the ability to pass DOM (or other Java) objects to to-be-executed XQuerys and to obtain results as Java objects?
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.
When doing Open Source, you'll learn that people base their judgment on what they need and try.
I can't really make a judgment about the stability of BaseX's XQJ implementation because I haven't gotten it working yet. For me, it failed at the first operation I tried. In my opinion, I wasn't stressing it with test cases such as the one I sent you, either. This means the existing testsuite is likely highly deficient (which in turn could be explained by the skepticism and abandonment XQJ appears to be facing, judging on your earlier pointers to discussions in the community.)
BTW, we already have some investment in BaseX. Our student spent 6 months getting a raw prototype of our application working, along with ca. 15 queries written using XQJ. Unfortunately, he was using the wrong namespaces and so didn't encounter these problems. So, my efforts here are to see if we can salvage our efforts or which alternative to chose.
It would probably take me a day to rewrite our XQJ code to use something else, but I first want to make sure I understand what the options are.
Adding support for the EventTarget interface might be an interesting extension as well, but it's not a mandatory part of the standard.
(*) 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.
Since I need support for EventTarget, I have no choice but to serialize the DOM object returned by BaseX's XQJ implementation and parse the resulting XML into a DOM object using the JDK's DOM implementation which supports the now 10-year-old DOM Level 2 Event Standard: http://www.w3.org/TR/2000/REC-DOM-Level-2-Events-20001113/
Is my understanding correct?
- Godmar