[xquery-talk] Extending Saxon (Barxon, Fooxon, ...).

[Adam Retter]

> the Saxon processor has a very interesting feature - "Integrated Extension
> Functions" - which amounts to the possibility to plugin own (custom or
> standard) Java functionality into the XQuery processor, by writing a little glue
> code. This has important advantages compared to the traditional approach of
> "reflexive" extension functions, see
> http://www.saxonica.com/documentation/extensibility/integratedfunctions.xml for
> details.
>
> *** Question:
> Are there other processors offering a similar extensibility, based on
> writing glue code?

Sure, we have offered this in eXist-db since around 2005 or earlier in
Java, Scala or potentially C++ through JNI.
Sedna supports basic external functions on atomic values in C++.
Zorba also has support for composing external functions in C++.


> Suppose there *are* (or soon will be) other processors, Fooxon and Barxon. It is
> clear that the glue code they require is different from the glue code which
> Saxon requires. But the information input determining how to write the glue code
> should be approximately the same (signatures and a little more).

This is true and a concern of the EXPath project. Just this last week
I have been collaborating with Florent and I believe that the guys
with Qizx have been involved as well. For example for the EXPath HTTP
Client module, there is a generic library http-client-java, for which
you can just implement some Glue code, and this Glue has indeed been
implemented for Saxon and eXist-db.

> How about code
> generation, taking as input a generic XML description of the extension functions
> and their binding to Java methods? This way we could have a set of code
> generators generating from a single, generic description: Saxon glue
> code, Fooxon glue code, Barxon glue code, ...

In eXist-db we are considering moving to a more flexible mechanism for
describing and packaging extension functions. At present this
information is held in String constants in Java files. We have
considered an XML manifest which describes the module, namespaces and
arity and type of parameters of extension functions within the module.
If this format was something that could be agreed and standardised by
EXPath then all the better. From something like this, code generation
or integration should be trivial. Although we would not necessarily
need code generation, as this aspect would be integrated directly into
the vendors product and would presumably be transparent to the user.

> This would amount to a new kind of portability. Note the similarity to code
> generation from WSDL. There, functionality is plugged into the www, and the
> generated code is generic. Here, functionality is plugged into XQuery
> processors, and the generated code is processor-specific. So...

Well I think it is probably impossible to describe the entire
implementation of the function in a language-agnostic way. You could
of course abstract away the glue, as you described above.

> *** Question: what do you think of generalizing the Saxon approach, by
> a) encouraging all implemetators to support (an own flavor of) Integrated
> Extension Functions

Most do.

> b) defining a generic extention function description language (our
> EFDL, so-to-speak),

Sure, a job for EXPath I think, perhaps you would contribute?

> c) encouraging implementators to provide their specific code generator (EFDL ->
> glue code)

Sure, I think all implementers should work with EXPath to implement
there recommendations.

> Thank you for thougts and comments,

Are you attending XML Prague? There will be some talks on EXPath
there, and it would be good to discuss your ideas.

>
>
>
>
> _______________________________________________
> talk at x-query.com
> http://x-query.com/mailman/listinfo/talk
>



-- 
Adam Retter

skype: adam.retter
tweet: adamretter
http://www.adamretter.org.uk