RE: types of numeric literals and operators

> The draft states (3.1.1) that an integer literal like 1 has
> the type xs:integer, not xs:int, even if it is
> in the value range of int.

I assume you are aware if you want the WG to look at this, you have to
submit a comment to public-qt-comments@w3.org.

> 
> Therefore an expression as simple as 1+1 should be resolved
> by the static type checking as an invocation of:
> 
>     op:add( x as xs:integer, y as xs:integer ) as xs:integer
> 
> Since xs:integer is of arbitrary precision, its
> implementation is likely to be heavy, and this would probably 
> lead to an inefficient implementation.

Firstly, xs:integer does not have to be "arbitrary precision". The Schema
spec allows implementations to impose a limit, and allows that limit to be
as low as 64 bits.

Secondly, there's nothing in the spec that stops you using int or short
arithmetic if you know statically that the values are in that range.

I think there is actually still a little ambiguity as to the result of 1+1.
We say that the result must be an xs:integer, but it's not clear whether an
implementation is permitted to return a value that is a subtype of
xs:integer. In my view, it should be allowed to do so, since such a result
would be consistent with the signature. This does potentially give an
interoperability problem in that the result of ((1+1) instance of xs:int)
becomes implementation-defined.

> 
> Moreover, an error should be detected in this apparently 
> innocent code (because 1 is of type xs:integer):
> 
>    define function funny( $x as xs:int ) as xs:int { $x + 1 }
> 
> * suggestions:
> 
>    1) specify that an integer literal has a minimal type (derived from
>       integer) that fits with its value (for example 10 would be int,
>       10000000000 would be long)

Unfortunately there are three "minimal types" that a number like 7
satisfies: xs:byte, xs:unsignedByte, and xs:positiveInteger. If you choose
any one of these three, then 7 will not be acceptable as a parameter to
functions declared to expect the other two.

Further, all three of these types are machine-oriented rather than
application-oriented. As soon as you start defining a type like day-of-week,
with a range of 1-7, then you're back in the same problem. And in my view,
we should not be encouraging users to use hardware-oriented types in their
application schemas. I don't think we should make it easier to use xs:int
than my:day-of-week; in both cases, casting will be necessary.

Finally, I don't think we should define that short+short=short, as is true
in many programming languages, because it isn't true in real life. The
result of 50000+50000 is not a short. And if that's the case, then the value
of making 50000 a short is marginal: it means you can pass 23 to a function
that expects a short, but not 17+6. 

Michael Kay

Received on Monday, 23 June 2003 11:42:21 UTC