Hi Hans-Jürgen,
Yes, that's what I am looking for. Will read that paper.
Thanks,
--Marc
On Tue, Apr 5, 2016 at 5:22 PM, Hans-Juergen Rennau <hren...@yahoo.de> wrote:
> 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
>
>
> [1]
> http://www.balisage.net/Proceedings/vol5/html/Rennau01/BalisageVol5-Rennau01.html#d64477e307
>
>
>
--
--Marc
