Re: Why does the addition of one (1) to a positiveInte

Any distinction between types that do not reduce the number of
permissible values is close to a placebo ;-)

One could argue that (guessing!) that in the case of f:iter(ate)
parameters <= 0 could be handled easily by doing nothing. And one
might also claim that Googol or Googolplex are not reasonable inpit
values; hence explicit range checking might be better than relying on
xs:someType,(and result in better error messages, too).

YMMV.
-W

On 29 August 2010 22:46, Michael Kay <mike@xxxxxxxxxxxx> wrote:
>
>> When I run this I get an error, "The argument to f:iter is
xs:positiveInteger, the supplied value is xs:integer"
>>
>> What is the rationale for this? After all, if I add one (1) to any
positiveInteger the result must be a positiveInteger.
>>
>
> There might be logic for saying that the result of xs:positiveInteger +
xs:positiveInteger should always be xs:positiveInteger, but a rule that says
xs:positiveInteger + xs:integer gives xs:positiveInteger provided that the
xs:integer is positive (or provided it is greater than the negation of the
first argument?) would be rather arbitrary.
>
> Generally I would advise against writing a function that expects subtypes of
xs:integer as an argument, because you will never be able to supply the
argument as a simple literal. These types were designed for validation, not
for type-checking programs. That's why, for example, the standard functions
insert() and remove() declare the expected type as xs:integer rather than
xs:positiveInteger. (It's also why in XSLT 2.0 types such as
xs:positiveInteger were excluded from the set of types recognized by a basic
XSLT processor). If you want to reject negative integers, do it by conditional
code in the body of the function, not by means of the type signature.
>
> Michael Kay
> Saxonica