This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
position should be allowed to be empty. Often this value is being calculated and the static type of the calculation will result in an optionally empty type. Proposed rewording: fn:insert-before( $target as item()*, $position as xs:integer?, $inserts as item()*) as item()* Summary: Returns a new sequence constructed from the value of $target with the value of $inserts inserted at the position specified by the value of $position. (The value of $target is not affected by the sequence construction.) If $target is the empty sequence, $inserts is returned. If $inserts is the empty sequence, $target is returned. If $position is the empty sequence, the error FORG--99 is being raised. The value returned by the function consists of all items of $target whose index is less than $position, followed by all items of $inserts, followed by the remaining elements of $target, in that sequence. If $position is less than one (1), the first position, the effective value of $position is one (1). If $position is greater than the number of items in $target, then the effective value of $position is equal to the number of items in $target plus 1. Add FORG--99 as: Invalid position has been passed to fn:substring, fn:insert-before, fn:remove or fn:subsequence.
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)
I understand your comments, but so far we have followed the philosophy that I outlined earlier. And unlike the "optimistic" type checking, the static type checking is actually part of our specification. So I still think we need to make this change. Especially since in most cases, you can actually return a meaningful result (note that I only added one new error condition).
The working group considered this comment at its meeting today and decided not to accept it. For rationale, please see bug 1467.