[Bug 5632] [UPD] Update primitives should be error-free

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

           Summary: [UPD] Update primitives should be error-free
           Product: XPath / XQuery / XSLT
           Version: Candidate Recommendation
          Platform: PC
        OS/Version: Windows XP
            Status: NEW
          Severity: normal
          Priority: P2
         Component: Update Facility
        AssignedTo: andrew.eisenberg@us.ibm.com
        ReportedBy: mike@saxonica.com
         QAContact: public-qt-comments@w3.org


Generally, the XQuery update specification is written so that dynamic errors
are detected as early as possible: either when the updating expression itself
is evaluated, or when testing the consistency of the updates within the Pending
Update List. There are two exceptions, errors that are described as occurring
during the application of update primitives.

The first is in upd:delete: "If $target has no parent, the XDM instance is
unchanged. An implementation may (but is not required to) raise a dynamic error
if $target had no parent before execution of the query began. [err:XUDY0020]."
This error condition belong much more naturally in the rules for the delete
expression (and indeed it is mentioned there, though only in a Note).

The second is XUDY0024. This occurs when two update primitives in the PUL would
cause conflicting namespace bindings to be added to the same element. (It is
phrased as if it also occurs when a new namespace binding conflicts with a
namespace binding that was there before the update started, but in fact all
such cases are caught earlier, as XUDY0023.) XUDY0024 can be expressed as a
consistency constraint on the content of the pending update list. All other
such constraints are described in the rules for upd:mergeUpdates and
upd:applyUpdates. 

Does this make any operational difference? In the absence of try/catch, perhaps
not. But with try/catch it becomes significant which expression has failed, and
an error described under upd:mergeUpdates() can be raised during the evaluation
of the expression that caused a primitive to be added to the PUL. Also, of
course, some implementations may find it helpful to perform all the consistency
checks on the PUL before applying any updates, as this makes it easier to
achieve atomicity; it would therefore be helpful to readers to describe
XUDY0024 as a constraint on the consistency of the PUL.

The error could be described like this (in 3.2.1 and 3.2.2):

e. Multiple namespace bindings are created for the same element by primitives
on (the merged list | $pul), such that two or more such namespace bindings have
the same prefix (or absence of a prefix) and different namespace URIs.
Primitives that create a namespace binding are:

  i. upd:insertAttributes creates one namespace binding on the $target element
corresponding to the *implied namespace binding* of each attribute node in
$content

  ii. upd:replaceNode creates one namespace binding on the $target element
corresponding to the *implied namespace binding* of each attribute node in
$replacement

  iii. upd:rename creates a namespace binding on $target, or on the parent of
$target if $target is an attribute node, corresponding to the *implied
namespace binding* of $newName.

Received on Monday, 7 April 2008 17:21:43 UTC