Subject: Re: [xsl] The Perils of Sudden Type-Safety in XPath 2.0 From: Gunther Schadow <gunther@xxxxxxxxxxxxxxxxxxxxxx> Date: Wed, 19 Feb 2003 18:09:41 -0500 |
Backwards compatible mode 1.0 doesn't help me at all. At least in previous versions of Saxon, if I specified 1.0 I even had to jump through the exsl:node-set hoops again. I definitely don't want to do that.
I agree to Michael saying implementation prior to freezing the spec is a good thing. From that experience I'd say the spec should get rid of the rigid pro-forma type checking. Get rid of that, it breaks so many things!!
Hmm... Interestingly in the light of what I said above, this seems to work if version="2.0" but not if version="1.0".
Yes. It's a bug in the spec, which has been pointed out and is being corrected, but it seems I implemented the spec as written before I noticed it! This is why it's a good idea to implement specs before they are frozen.
The corrected spec says that in backwards compatibility mode, the cast is only attempted where the target type is double or string. That catches all the 1.0 functions.
In 2.0, you always get a cast to the required type when the supplied
value is an untyped node (that is, a node from a schema-less document).
Michael Kay
Software AG
home: Michael.H.Kay@xxxxxxxxxxxx
work: Michael.Kay@xxxxxxxxxxxxxx
The signature for string-pad() is:
string-pad($padString as xs:string, $padCount as xs:integer) as xs:string?
It works if version="2.0" because the type of the value of the @indent attribute is xdt:anyAtomicType, and when you pass a value of type xdt:anyAtomicType as an argument to a function it just gets converted automatically to the required type for the argument. So in this case the xdt:anyAtomicType value from the indent attribute gets converted to an xs:integer.
On the other hand, if version="1.0" and the backwards compatibility flags apply then a numeric required type for the argument entails converting the argument to a xs:double value. As you've found, the xs:double value then can't be automatically converted to an integer, which is why you need the explicit cast. This isn't an issue with the XPath 1.0 functions because they all expect doubles, but as you've found, several of the new functions only accept integers.
(FWIW, I thought that floor(), ceiling() or round() might help here, but they all return doubles, I think for compatibility with XPath 1.0, so that they can return NaN.)
So the fix here, if you want to avoid declaring and using the XML Schema namespace, actually seems to be to use version="2.0" rather than version="1.0".
Cheers,
Jeni
--- Jeni Tennison http://www.jenitennison.com/
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
-- Gunther Schadow, M.D., Ph.D. gschadow@xxxxxxxxxxxxxxx Medical Information Scientist Regenstrief Institute for Health Care Adjunct Assistant Professor Indiana University School of Medicine tel:1(317)630-7960 http://aurora.regenstrief.org
Current Thread |
---|
|
<- Previous | Index | Next -> |
---|---|---|
RE: [xsl] The Perils of Sudden Type, Michael Kay | Thread | RE: [xsl] The Perils of Sudden Type, Passin, Tom |
RE: [xsl] xslt coding conventions, Conal Tuohy | Date | Re: [xsl] The Perils of Sudden Type, Charles White |
Month |