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 4526 - [UPD] Sections 2.4.*: Target should allow empty sequence
Summary: [UPD] Sections 2.4.*: Target should allow empty sequence
Status: CLOSED FIXED
Alias: None
Product: XPath / XQuery / XSLT
Classification: Unclassified
Component: Update Facility (show other bugs)
Version: Working drafts
Hardware: PC Windows XP
: P2 critical
Target Milestone: ---
Assignee: Andrew Eisenberg
QA Contact: Mailing list for public feedback on specs from XSL and XML Query WGs
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2007-05-04 23:21 UTC by Michael Rys
Modified: 2007-06-09 00:14 UTC (History)
1 user (show)

See Also:


Attachments

Description Michael Rys 2007-05-04 23:21:28 UTC
Update target should allow empty sequence to make this usable in a static typing context. Semantics where target is empty is a no-op.

Currently an expression such as (/a/b)[1] as a target will most likely fail because it is statically typed as b?.
Comment 1 Jonathan Robie 2007-05-08 17:20:33 UTC
I don't like the idea of changing this in the dynamic semantics. If a user attempts to add a new child to an existing element that does not exist, I think the user should be made aware of the error - ignoring this silently will make it harder to find bugs.

In the static semantics, I'm somewhat sympathetic, but I can also live with the status quo. I think XQuery's static semantics currently require users to do more work than they should for cardinality constraints, and implementations have often decided to relax these constraints. In keeping with what many people are currently implementing, I think relaxing this statically makes sense - but to *, not to ?. On the other hand, it might be better to have consistency now, and review the usability of the static semantics of the language as a whole in vNext.
Comment 2 Don Chamberlin 2007-05-12 00:13:20 UTC
I agree with Jonathan that attempting to insert a node into a non-existent target should be at least a dynamic error. Regarding static checking, I don't see why this case should be treated differently from other pessimistic static checks (for example, (/a/b)[1] + 47 is also a static error for the same reason cited by Michael.)
--Don Chamberlin
Comment 3 Michael Rys 2007-05-12 00:20:31 UTC
First (/a/b)[1] + 42 is not a static error. The semantics is clear for the empty sequence: "If the atomized operand is an empty sequence, the result of the arithmetic expression is an empty sequence", and the static typing allows the above expression.

I personally think that making the inserting into empty a no-op or dynamic error is ok with me, but I want to not have this raised as a type error and only raise type errors if more than one target node is being specified.
Comment 4 Jonathan Robie 2007-05-22 14:18:14 UTC
I have been asked to draft a change proposal. I believe we can make the desired change by changing the word *** type *** to *** dynamic *** in the following places.

2.3.1 Insert

Semantics, bullet point 2:

"The target expression is evaluated. If into is specified, the result must be a single element node or a single document node; otherwise a *** type *** error is raised [err:TBD]. If before or after is specified, the result must be a single element node whose parent property is not empty; otherwise a dynamic error is raised [err:TBD]."

2.3.3.2 Replacing the Value of a Node

Semantics, bullet point 2:

The target expression is evaluated. The result must be a single node; otherwise a *** type *** error is raised [err:TBD].

2.3.4 Rename

Semantics, bullet point 1:

The target expression is evaluated. The result must be a single element, attribute, or processing instruction node; otherwise a *** type *** error is raised [err:TBD].
Comment 5 Don Chamberlin 2007-06-09 00:09:16 UTC
Michael,
On May 22, 2007, the Query Working Group considered this bug report and agreed to reduce the amount of static checking that is required for the target of an updating expression. Static type checking will only be required to check that, if the target expression returns a non-empty sequence, it is a single node of an appropriate kind. All other errors relating to the target expression will be dynamic errors. This includes the case where the target expression returns an empty sequence, which will raise an new error code XUDY0027.

Since you were present for the discussion and agreed with the result, I am marking this bug as "Fixed and Closed."

Don Chamberlin (for the Query Working Group)
Comment 6 Don Chamberlin 2007-06-09 00:14:50 UTC
Some more details on the resolution of this bug report:

The type errors relating to the target of an updating expression are XUTY0005, XUTY0006, XUTY0007, XUTY0008, and XUTY0012. 

All other errors relating to the target of an updating expression are dynamic errors. This includes XUDY0009, XUDY0010, XUDY0011, XUDY0022, XUDY0023, XUDY0025, XUDY0027, XQDY0026, and XQDY0072.