RE: [xsl] Typing of parameters in XSLT 2.0

Subject: RE: [xsl] Typing of parameters in XSLT 2.0
From: "Michael Kay" <mhk@xxxxxxxxx>
Date: Wed, 16 Apr 2003 23:29:35 +0100
> 
> 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


Current Thread