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

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


Hi Georges,

you wrote:
>>>
" 2/ the "glue code" is often very simple (usualy implementing a
    specific interface and registering the resulting class on
    the processor); I don't really see the advantage of
    generating this code, even though it could sometimes ease
    some aspects (especially checking the number and type of
    parameters from an abstract signature)"
<<<

The "register the interface" approach is convenient, but it is a runtime affair. 
I am sure that Michael Kay had good reasons to impose the writing of glue code, 
opted for compile-time integration in spite of the inconvenience to the 
programmer. Therefore: you are right with your "very simple" if you are content 
with runtime registration, not when aspiring to the static integration offered 
by Saxon. (I doubt if anyone who has written Integrated Extension Function à 
la Saxon would call the endeavour "very simple".)

>>>
" 3/ what is trickier is the access to the processor object
    model: even in the same language (say Java), each processor
    has its own object model (that is, the way it represents an
    XDM instance)
<<<

I think it is very important to distinguish the code to be made available as 
extension functions and the glue code:
a) the code to be made available as extension functions (let me call it the 
"functional code") should not be expected to know the processor
b) the glue code is processor specific

The functional code should have anything to do with XPath or XDM. The Java 
signatures to be bound to XPath signatures should speak of String, int and Node 
and be free to use arrays and collections - rather than speak of XdmAtomicValue, 
XQItem or XQSequence. In general, any standard Java functionality should be a 
candidate for being made available as extension function.

Therefore - if there is anything "tricky", then it is exactly the glue code to 
be written or generated, creating behind the scenes entities of that "own object 
model".

>>>
"4/ the approach used by the open source implementations of the
    EXPath modules HTTP Client and ZIP is to define a few simple
    interfaces that abstract access to the object model, as well
    as creating it.  So most of the code is generic for a Java ..."
<<<

This is a different type of portability: portability via common APIs which will 
be supported here and there. The portability I am thinking of is totally 
independent of specific interfaces, it is a plug-in approach: 
participating processors offer the facility to plug in what you bring along - 
plug it in at compile time.

The "common API" kind and the "plug-in" kind of portability both have their 
value, I think, and cannot replace each other. I am eager to learn how EXPath 
views the plug-in kind, and looking forward to discussions in Prague!

Kind regards,
-- Hans






More information about the talk mailing list