[xsl] typing of integer operations in Xpath2

[David Carlisle <davidc@xxxxxxxxx>]

[
 This comment has been posted to the official comment list
 http://lists.w3.org/Archives/Public/public-qt-comments/2004Apr/0116.html
 but I repost here as I wonder if other people have similar experiences?
]

This comment isn't related at a specific document but is rather a
cross-document comment on the current typing rules.

I've been trying to write some "new" xslt2 stylesheets (as opposed to
converting existing xslt1 ones, or simple one-liners answering questions
on xsl-list).

I have to say that the type system is a continuous source of irritation.

In a strongly typed language such as Standard ML in which the type
system is closely matched to the underlying data and the type inference
rules, you never (well, almost never) have to explicitly declare the
types of values, and the type system works as an aid to trapping errors
early.

Here though, the type system generates far more errors than it will ever
catch, almost all the type errors I am getting are due to failures in
the type inference system and not related to any real underlying error
in the code. The end result is that I continually have to add explicit
xsl:integer() all over the place in places that are very hard to
remember or work out in advance, you are more or less forced to just run
it and then add the casts until the errors go away, which is a very
frustrating mode of working.

If I see

Required type of second operand of 'to' is xs:integer; supplied value is xs:double

again I think I'll scream!

My stylesheet is manipulating unnamespaced-unvalidated elements which
have lots of integer valued attributes height="3" etc.
As neither the input nor the output use schema, and the integer type is
built in to Xpath in the sense that integer literals  and integer valued
functions are available without explicitly loading the xsd namespace,
one may have hoped to be able to compute with these values in a natural
way, but this is not the case.

You are constantly caught out by the fact that while the attribute value
may be used directly as an integer, as soon as you do any kind of
computation with the value (even if all computations logically result in
integers) you end up with a double. In my stylesheet all input values
are integers and the only operations I use are:
 + - idiv min max and sum.


There are several possible strategies that could be taken to alleviate
this problem, The Working group would have a better idea than me on
the possible effects on other parts of the language (you have probably
considered these already, but it's hard to see how any of them could be
worse than the status quo)

1) all xpath operators and built in functions could use double rather
  than integer so xs:integer would just be used for validation purposes
  but all operations would first cast to double. This is effectively the
  Xpath 1 solution.


or

2) the numeric promotion rules could be extended to allow silent
   automatic casting between double and integer in the case that the
   value is actually an integer

or

3) more generally the casting rules could allow silent casting between
   _any_ two types if the cast would succeed. (I don't think you'll go
   for this one:-)

or

4) Given an "untyped" value from the source the operations would cast to
   the required type (as now) but then also untype the result so that
   I am not caught by this continual automatic casting to double.

or 

5) If the untyped value is in the lexical space of integer the
   arithmetic operations cast it to integer rather than double

or 

6) ...


David

________________________________________________________________________
This e-mail has been scanned for all viruses by Star Internet. The
service is powered by MessageLabs. For more information on a proactive
anti-virus service working around the clock, around the globe, visit:
http://www.star.net.uk
________________________________________________________________________