[xquery-talk] Extending Saxon (Barxon, Fooxon, ...).
hrennau at yahoo.de
Sat Mar 19 23:57:02 PST 2011
" 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
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
"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!
More information about the talk