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

Hans-Juergen Rennau hrennau at yahoo.de
Sat Mar 19 13:53:41 PST 2011


Hi Adam,

thank you very much for the very interesting information - I am surprised to 
hear how popular this approach already seems to be! But one thing is not clear 
to me - how similar are the *models* of function execution behind it? Namely, 
how about object constructors and instance level methods, which require an 
object management behind the scenes which is tied to a single query execution, 
and a convention how function parameters can identify object instances. With 
Saxon, instance level methods are possible, though not trivial. How about other 
processors?

A few things you wrote make me unsure if we have exactly the same approach in 
mind. My doubts arise from two remarks of yours. You wrote:

a) 
"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."

And b)
"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."

ad a)
Let me clarify my goal: a completely generic mapping of abstract function 
descriptions (the manifest you speak of?) to the glue code. From this point of 
view it is totally irrelevant how one defines specific libraries, like the 
http-client library. To design such libraries makes sense from a different point 
of view, of course, but if there is something special about the glue code for 
one library compared to the glue code for a different library, then we are not 
speaking of exactly the same thing.

ad b)
What does it mean, "integrated into the vendors product"? I am very curious. But 
if there is no need to create glue code (either by code generation or by hand) 
when specific functions are to be made availabe - then, again, we are perhaps 
speaking of slightly different approaches. 


Finally you wrote:

c)
"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."

ad c)
A misunderstanding - the "description of the implementation" I have in mind is 
essentially a mapping of function name to Java method name (or Java field name), 
of function parameters to method parameters (including data conversions, 
where non-standard) and function parameters to object identity (in the case of 
instance methods). Full stop. And that - should be possible in a generic way.

I am looking forward to discuss with you in Prague!

Thanks again, kind regards,
-- Hans-Juergen


 
----- Ursprüngliche Mail ----
Von: Adam Retter <adam.retter at googlemail.com>
An: Hans-Juergen Rennau <hrennau at yahoo.de>
CC: talk at x-query.com
Gesendet: Samstag, den 19. März 2011, 11:15:38 Uhr
Betreff: Re: [xquery-talk] Extending Saxon (Barxon, Fooxon, ...).

> 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






More information about the talk mailing list