In the absence of an as attribute or a type-information
attribute on the
<xsl:param> element the stylesheet seemed to behave in XSLT
2.0 as it did
in XSLT 1.0.
That is convenient but I am not sure that I completely
understand the XSLT
2.0 processor's behaviour.
Let's say the command line was java -jar saxon7.jar ..... number=5.
What type is the supplied parameter 5 in XSLT 2.0? I couldn't
find a clear
description in the spec.
That's because the command line, and APIs generally, are outside the
scope of the spec.
Saxon is treating any parameter supplied from the command line as a
string. From the Java API, you can supply other types. The conversion
rules are the same as for values returned from Java extension functions.
At present (in Saxon 7.4) these still do liberal type conversion, based
originally on the Java language binding in the XSLT 1.1 WD. At some
stage I will probably align the type conversion with the stricter rules
defined in 2.0. My thinking is that a value supplied on the command line
will be treated as untypedAtomic, which means it will still be cast to
the required type declared for the parameter.
Is the supplied parameter a string which is then
automatically cast to an
XPath 1.0 number?
In the processing of the $number parameter and the
variable(s) used to
recursively calculate the factorial it was being treated as
some type of
number, since I could perform both subtraction and
multiplication on it. An
XPath 1.0 number? Or an xsd:integer??
In the absence of both an as attribute and a type-information
attribute is
an XSLT 2.0 processor expected to produce the same behavior
as in XSLT 1.0
and automatically treat parameters "intuitively"? Or is the Saxon 7.4
behaviour a carry over from its XSLT 1.0 heritage?
It's to a large extent a carry-over, but I think the right approach is
to do the same conversion for command line parameters as for text in
schemaless documents, which means you will continue to get implicit
casting.
Michael Kay
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list