Hi Marc,

like you, I find the integration of XQuery results into other languages a most interesting topic, and I think it is a topic deserving more attention from the XML-community than it receives.

I feel that the integration should completely hide the fact that XQuery is a different language than the host language, that is, the query results should be delivered in *exactly* that format which the host language programmer desires. From this perspective, XQuery plays the role of an information service to the host language application. The XQuery programmer is responsible for writing queries which deliver information as an XDM representation of the information desired by the, say, Java programmer. The query is designed to produce a result XDM which the host language infrastructure (high-level API) transforms into the desired "final" format without the application programmer ever being aware of the XDM origin. To achieve an unambiguous correspondance between XDM and non-XDM, the query may augment the result with additional XDM items ("meta items") providing meta data about how to transform the (primary) XDM items into host language items (e.g. meta items defining the mapping of an XML fragment to a host language map via XPath expressions, or segmenting the XDM sequence into subsequences corresponding to distinct host language items.)

The key to all this is a high-level API which completely hides the conversions between host language types and the XDM. Such an infrastructure must be built upon a low-level API like XQJ or the equivalent s9api of Saxon - which bridges the host language type system and the XDM type systems. The higher level API is responsible for *all* conversions between host language type system and XDM. I suggest a long series of XQuery execution functions with known result types, like

   execQuery2string

   execQuery2strings    (: returns String[] :)

   execQuery2int

   execQuery2ints         (: returns int[] :)

   ...

   execQuery2map_string_string

   execQuery2map_string_int

   ...

   etcera!

from which the host language programmer chooses. The choice is dictated by the actual query to be launched: each published query has a known signature described in terms of host language types like integer arrays and string-to-boolean maps. So any given query has to be launched with a particular variant of execQuery, and this query delivers the desired data type.

The approach can be extended in various way, for example by supporting the delivery of complex containers of information ("info trays") consisting of named entries each one of which has its own and independent type ( [1] ).

So in summary I believe there are very interesting possibilities of integrating XQuery seamlessly into other languages, and the foundation is a low-level API preserving XDM type information. All else can be built on that.

Cheers,

Hans-Jürgen