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

[Michael Kay]

> 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). 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, ...
>
> 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...
>
> *** Question: what do you think of generalizing the Saxon approach, by
> a) encouraging all implemetators to support (an own flavor of) Integrated
> Extension Functions
> b) defining a generic extention function description language (our
> EFDL, so-to-speak),
>
> c) encouraging implementators to provide their specific code generator (EFDL ->
> glue code)
> ?
>
There was an attempt in 2001 to standardize interfaces to XSLT extension 
functions written in Java (see http://www.w3.org/TR/xslt11/). It met a 
rather hostile reception, for reasons I now find it difficult to recall, 
except that some of the most vocal criticism was people who felt Java 
should not be accorded any special status in the XSLT specification. 
Since then W3C has tried to avoid getting involved in host-language 
specific standards.

The XQJ effort is also a rather unhappy precedent: it took years to get 
the standard finished, and when it was done, it was not a very 
satisfactory standard.

You seem to be proposing something slightly different, not a standard 
API for extension functions, more a kind of meta-standard. It feels to 
me a bit like specifying the interfaces in IDL - again, the use of IDL 
to specify DOM in a language-independent way is not a very inspiring 
precedent, since it led to the development of a Java API that ignores 
all the usual Java ways of doing things.

Michael Kay
Saxonica