> It says in the Saxon extension function documentation on
> Instance-level methods
> that "A Java Object is usually created by calling an
> extension function (e.g. a
> constructor) that returns an object; it may also be passed to
> the style sheet as
> the value of a global parameter"
> Is it possible to pass objects to the XQuery implementation
> as well?
Yes, external variables in XQuery are implemented in exactly the same way as
stylesheet parameters in XSLT.
> If so, how
> is this done, as I've tried a few variations on the following
> approach without
> declare namespace date="java:java.util.Date";
> declare variable $currDate as date external;
If I do this:
declare namespace date="java:java.util.Date";
declare variable $currDate as xs:dateTime external;
and invoke it from the command line as:
java -cp c:\MyJava\saxon8.jar net.sf.saxon.Query c:\temp\test.xq
then the result is:
<?xml version="1.0" encoding="UTF-8"?>
A parameter passed on the command line is interpreted as being
xdt:untypedAtomic, and it is therefore implicitly converted to the required
type of xs:dateTime (I've just realized this will stop working when I
implement the stricter type checking rules for "declare variable", which do
not allow such a conversion, but currently the code implements the XSLT
In your example you declared the type as "date" without qualification. I
would expect this to be rejected as an unknown type.
If you pass the parameter from Java code, you must pass something that Saxon
regards as convertible to xs:dateTime. For example, you can pass a
In this example we are using a standard XPath built-in type. In principle
you could also define the parameter as belonging to an external Java type,
declare namespace j as "http://saxon.sf.net/java-type"
declare variable $currDate as j:java.util.Date external;
However, this only works for classes where there isn't a correspondence to a
built-in XPath type. Saxon (currently) works from the supplied value rather
than the required type, and when it sees that you have supplied a Date, it
assumes you want that handled as an xs:dateTime. There's scope here for a
smarter approach that takes account of the required type.