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

[David Lee]

Hans and Georges write ....
----------------------------------------------------------------------
>>>
" 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".
----------------------------------------------------------------------------
---------------------

--> Me 

I suggest there are 2 useful models to consider.  The one Hans suggests
where code already 'exists' (say an HTTP or Gzip library ) and it needs to
be called from XSLT/XQuery.
In which case these arguments are valid.

Then there is another case, where some of the details of the integration are
desirable and used.   For example cases where a function wants access to the
context node.
say like
	/foo/bar/ns:myfunct()/spam

For a specific example to get the idea,  xmlsh exports an "eval" function to
saxon and this can be used among other things to call xslt from xquery.

http://www.xmlsh.org/XPathExtension

This allows this somewhat interesting construct from within XQuery (or
xpath)

	/foo/bar/xmlsh:eval("xslt -f style.xsl")/spam

For something like this, it would not do at all to use a generic access to
things like w3c.dom.Node.    the overhead of having to wrap the native
classes to generic classes and back is not acceptable or desirable.   Use of
the native processor classes is really what is needed.

However I suspect this is a small set of use cases.  Most (if not all except
the above)  uses of extension functions I've seen which are not vendor
supplied have very simple expectations of the context.  They do fit the
model of "pre existing code I want to call from XQuery/XSLT/XPath"  rather
than making heavy use of the somewhat exotic capbilities.

-David












----------------------------------------
David A. Lee
dlee at calldei.com
http://www.xmlsh.org