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

Hans-Juergen Rennau hrennau at yahoo.de
Sat Mar 19 23:16:10 PST 2011


Hello Michael, 

you wrote:

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

Special status? What I imagein is a description in two levels: 
   a) implementation language independent (mainly the function signature), 
   b) implementation language dependent (class name and method name - what 
else?). 

As far as I can see, b) can be reduced to a couple of identifiers in the case of 
Java, also a couple of identifiers in the case of C++, a single identifier in 
the case of C, etc. How nice that we have namespaces, which make the description 
extensible - one description may even contain several language bindings. There 
is not special status given to Java.

>>> "You seem to be proposing something slightly different, not a standard API for 
>>>extension functions, more a kind of meta-standard."

Not slightly, but completely different. The portability I am thinking of has 
nothing to do with portability reached by "common APIs". 


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

Frankly, I do not need inspiration from IDL, because what could be done is clear 
and simple enough, and not imposing anything on the Java code. It is designed to 
make Java code *AS IS* available - see below.

>>> "... since the development of a Java API that ignores all the usual Java ways 
>>>of doing things."

Which API? Which Java ways will be ignored? The proposed approach does not 
create an API and does not impose anything on the Java developer: 

(1) Starting point: some Java functionality *exists*, (standard Java or custom 
classes and their methods).
(2) In order to make it accessible, all that needs to be done is (a) write an 
XML document and (b) push a button. 


-- Hans-Juergen






More information about the talk mailing list