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!!
-Gunther
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(_dot_)H(_dot_)Kay(_at_)ntlworld(_dot_)com
work: Michael(_dot_)Kay(_at_)softwareag(_dot_)com
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(_at_)regenstrief(_dot_)org
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
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list