[xquery-talk] Extending Saxon (Barxon, Fooxon, ...).
mike at saxonica.com
Sat Mar 19 18:02:42 PST 2011
> 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
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
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.
More information about the talk