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: Dimitre Novatchev <dnovatchev@xxxxxxxxx>
Date: Wed, 19 Feb 2003 03:11:07 -0800 (PST)
Jeni said:

"The backwards compatibility flag *should* make expressions that are
legal in XPath 1.0 do the same thing in an XPath 2.0 processor as they
do in a XPath 1.0 processor. It should make expressions that are not
legal in XPath 1.0 work roughly in the way that you'd expect them to
were the XPath 1.0 rules extended into XPath 2.0, though as you've
found you can't rely on this."

Then:

"Hmm... Interestingly in the light of what I said above, this seems to
work if version="2.0" but not if version="1.0".

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.)"


Kurt said:
"I've worked
with XPath for the last five years (counting the time very early on
when it
was a very different looking animal), and I think I've run into maybe
three
times in that period where having type-casting would have made things
easier, and that principally because XSL lacked certain pieces which
are
finally coming into play in XSLT 2. When you add type you increase the
complexity of the applications with relatively little beneft, UNLESS
you are
looking for ways to build a bundled data-aware object. In other words,
the
principal driving requirements for PSVI can be traced back to trying to
turn
XML into an OOP object. This can certainly be done, but at the cost of
losing much of the flexibility that makes XML so useful."


The difficulties that even Jeni has prove Kurt's point.

My question is: Isn't there any way simply to nlock all these type
checking, please?

Don't understand me wrong -- I do not need to be convinced and
persuaded about the benefits of having a strong type checking system. I
admire Haskell, which has it.

But XSLT is *not* Haskell. Introducing such strong type checking into
XSLT make it almost impossible to work (if even Jeni has such
difficulties. then no mortal XSLT programmer would be able to do
anything at all), will decrease to zero its users population and will
change XSLT into something completely different, which is not XSLT any
more.

Do the authors of this beast really listen to what we are saying?

Do they respect the XSLT programmers' community?

Will XSLT 2.0 really be XSLT?





=====
Cheers,

Dimitre Novatchev.
http://fxsl.sourceforge.net/ -- the home of FXSL

__________________________________________________
Do you Yahoo!?
Yahoo! Shopping - Send Flowers for Valentine's Day
http://shopping.yahoo.com

 XSL-List info and archive:  http://www.mulberrytech.com/xsl/xsl-list


Current Thread