Hi all,

Thanks both Charles and Jürgen for your comprehensive and enlightening answers. It is very good to hear that there is hope for XQJ even in an XQuery 3 world ;-) Beefing up the spec to XQuery 3.1 would be fantastic.

For the shorter term I'm thinking along the lines of a XDM transport serialization that includes type info and aims at efficiency rather than being human readable. As my host language of choice would be Clojure I am currently looking at Transit[1] which has both a Java and Clojure library and seems like a nice candidate but there are many others such as Avro, Thrift, Protocol buffers, Hessian etc etc. I might read up a little on those too[2].

[1] https://github.com/cognitect/transit-format

On Tue, Apr 5, 2016 at 9:04 PM, Charles Foster charles@cfoster.net wrote:

Hi Marc,

I plan to open source all the XQJ drivers I’ve written, (in the long-run).

The XQJ specification was designed to support XQuery 1.0 only, however I don’t see why it can’t be made to support XQuery 3.0 and 3.1 syntax to some extent.

Regarding XDM Maps and Arrays being bound to external variables and returned in result sequences along with the conversion between XDM and Java types wouldn’t be too difficult to achieve in practice.

Java’s List and Map classes spring to mind, along with XQItemAccessor getObject(...) [1] to retrieve and XQDynamicContext.bindObject(...) [2] to bind where you would of course have to do manual casting. The datatypes of Java's Map and Array entries and conversions between their XDM counterparts could be determined by following the rules already laid out in the XQJ spec itself [3].

One would of course be going above and beyond the original XQJ specification here, but I think technically it would still be within the rules and providing it was well documented I’m sure user’s could cope. I would love Oracle to update their existing XQJ specification to cater for XQuery 3.1 properly, I would even help them get there if they wished, but I don’t know if they would be up for something like this.

I think once the drivers are open sourced, the world of XQJ will be in healthier place for the community to update going forward.

Specifically regarding BaseX XQJ - for the moment, please assume that any of the driver’s provided by BaseX themselves are the latest and greatest.

Kind Regards,

Charles

P.S. Please come to XML London in June - it will be great!

[1] http://xqj.net/javadoc/javax/xml/xquery/XQItemAccessor.html [2] http://xqj.net/javadoc/javax/xml/xquery/XQDynamicContext.html [3] https://en.wikipedia.org/wiki/XQuery_API_for_Java#Default_data_type_mapping

On 5 Apr 2016, at 14:41, Marc van Grootel marc.van.grootel@gmail.com wrote:

...

Hi Christian,

Thanks. Very curious to hear about XQJ's fate.

I am currently using BaseX for data integration which got me thinking about integration of XQuery in other web applications (node/python/clojure etc.). I was triggered by the recent thread about node-basex[1] and Hans Jürgen and your Balisage paper [2]. I was considering what the most performant way would be to return XQuery results as native types. Eg. function returns an array with maps or XML nodes and it gets converted to the host application's native data types so the application can use the results as if they were native data types.

Maybe the only viable way to tackle this *is* via HTTP and a smart serialization (EDN[3] for example is such a, non-JSON, serialization that includes type info) but I was thinking if there was an existing lower-level way (without the BaseX HTTP layer). XQJ would enable this (at least for XQuery < 3) but I have doubts if it would deserialize non-atomic XDM values (like nested maps/arrays) as this is new to XQuery 3, I didn't check but I figure that the BaseXClient on which it is based also doesn't provide the XDM metadata for each nested item.

Just pondering how to bridge from XQuery to other languages.

On Tue, Apr 5, 2016 at 11:58 AM, Christian Grün christian.gruen@gmail.com wrote:

...

Hi Marc,

...

Is it right that the current XQJ driver for BaseX doesn't support XQuery 3 syntax? Everytime I try to use a query that includes some of the newer features it barks at me with Invalid XQuery syntax, syntax does not pass static validation. Is there way to get around that, say, when the result would not use these XQuery 3 data types?

I'm wondering what the fate is of XQJ in general. Will it remain relevant?

I decided to pass on your question directly to Charles Foster; he might be able to give you some outlook!

...

Also I am confused why files.basex /maven repo has XQJ driver 1.6.0 and xqj.net has 1.4.0 as the latest or what the difference is.

I have sent a pull request to Charles’ repo; it may be included in the next version there.

...

The reason I was looking into XQJ was that it provides ways to get XDM type info with the result. I would like to be able to deal with the result from a query at a higher level than just strings. I've briefly looked into BaseXClient.java which seems to be able to return XDM metadata but then I saw that XQJ could do this out of the box.

Right, that’s only possible with XQJ.

...

In general I would be interested to hear what the best way would be to get a client to deal with query responses as native (client-side) types (including hashmaps and arrays) instead of strings. Would it be better to focus on using BaseXClient and forget about XQJ?

From my perspective, it’s good to use XQuery whenever possible and use our Client Module to address BaseX server instances [1] ;)

Cheers, Christian

[1] http://docs.basex.org/wiki/Client_Module

-- --Marc