This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 1469 - [FO] fn:insert-before: allow empty sequence for position
Summary: [FO] fn:insert-before: allow empty sequence for position
Alias: None
Product: XPath / XQuery / XSLT
Classification: Unclassified
Component: Functions and Operators 1.0 (show other bugs)
Version: Last Call drafts
Hardware: PC Windows XP
: P2 normal
Target Milestone: ---
Assignee: Ashok Malhotra
QA Contact: Mailing list for public feedback on specs from XSL and XML Query WGs
Depends on: 1467
  Show dependency treegraph
Reported: 2005-05-19 20:06 UTC by Michael Rys
Modified: 2005-09-29 11:24 UTC (History)
0 users

See Also:


Description Michael Rys 2005-05-19 20:06:40 UTC
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.
Comment 1 Michael Kay 2005-05-20 14:06:46 UTC
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)
Comment 2 Michael Rys 2005-05-20 14:15:47 UTC
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).
Comment 3 Mary Holstege 2005-07-21 20:43:02 UTC
The working group considered this comment at its meeting today
and decided not to accept it. For rationale, please see bug 1467.