[Bug 1469] [FO] fn:insert-before: allow empty sequence for position

http://www.w3.org/Bugs/Public/show_bug.cgi?id=1469





------- Additional Comments From mike@saxonica.com  2005-05-20 14:06 -------
This comment relates to all this batch of "bugs" (it would have been better to
raise a single bug entry so they could be discussed together). 

While I accept that the distinction we have tried to make between principal
inputs and control arguments is a rather fine one, I think it is a bad idea to
widen the types accepted by all these arguments merely to make life easier for
people using static typing implementations. It has always been recognized that
people using static typing implementations are going to have to get used to
writing "treat as" or "exactly-one()" in many places.

Widening the signatures of functions to allow values for which there is no
natural result has a negative effect for the users of dynamic typing
implementations. It means that many errors will not be detected at all, and will
simply result in empty output; in such cases (as people trying to debug
XSLT/XPath 1.0 know) it can be very hard to trace the error back to its original
source. The experience to date of the stronger type checking in XSLT/XPath 2.0
is that many coding errors are easier to debug because they result in type
errors close to the point where the actual error is made.

Further, many systems implementing "optimistic type checking" (the specification
calls it "dynamic type checking", but that's not really the right term) report
type errors statically if the user does something obviously wrong, like
substring($x, 1, substring($y, 1, 1)). More specifically, such systems report an
error at compile time if the intersection between the static type of the
supplied value and the static type required is empty. Allowing an empty sequence
to be supplied removes the ability to report this case as an error, because the
intersection of string? and double? is not empty.

Michael Kay (personal response)

Received on Friday, 20 May 2005 14:06:55 UTC