Re: [xsl] The Perils of Sudden Type-Safety in XPath 2.0

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!!


Michael Kay wrote:
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".



Jeni Tennison

XSL-List info and archive:

Gunther Schadow, M.D., Ph.D.                    gschadow@xxxxxxxxxxxxxxx
Medical Information Scientist      Regenstrief Institute for Health Care
Adjunct Assistant Professor        Indiana University School of Medicine

XSL-List info and archive:

Current Thread