It looks to me as if your problems are mainly due to interactions
between the new type checking rules, which are defined in the XPath
specs, and Java extension functions, which aren't. It's quite possible
that extension functions need a bit of a rethink as to how they fit into
the 2.0 type system. Just be patient, tell me where the problems are,
and I'll look at them. I've always made it quite clear that Saxon 7.x is
trail-blazing and that it's not intended for the faint-hearted.
Michael Kay
Software AG
home: Michael(_dot_)H(_dot_)Kay(_at_)ntlworld(_dot_)com
work: Michael(_dot_)Kay(_at_)softwareag(_dot_)com
-----Original Message-----
From: owner-xsl-list(_at_)lists(_dot_)mulberrytech(_dot_)com
[mailto:owner-xsl-list(_at_)lists(_dot_)mulberrytech(_dot_)com] On Behalf Of
Gunther Schadow
Sent: 18 February 2003 18:10
To: xsl-list(_at_)lists(_dot_)mulberrytech(_dot_)com
Subject: Re: [xsl] The Perils of Sudden Type-Safety in XPath 2.0
Just a few example how much trouble this causes:
I had:
<xsl:value-of select="$x"/>
now suddenly make Saxon crash with ClassCastException! I
mean, come on, isn't it obvious that when I want to create a
text node that that object behind the variable is turned into
a string somehow? Even Java does that automatically!
I had
<xsl:if test="$x and not($x='')">
than now raises and error that xs:object supposedly doesn't
compare with xs:string! Get real! The xs:object in this case
actually happens to be a java.lang.String! I mean, how close
can you get?
Finally things now work just differently, I continue to get
crashes and stuff not terminating, and who knows what other
bad things are happening.
I now revert back to Saxon 7.3, this is killing me. I really
applaud Michael for his Saxon work, but this sudden move to
(needless) strict type checking without a way for migration
was a bad idea. Will I be forever stuck with Saxon 7.3?
-Gunther
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list