W3C home > Mailing lists > Public > public-qt-comments@w3.org > January 2009

[Bug 6495] New: [UPD] Consistency within deleted subtrees

From: <bugzilla@wiggum.w3.org>
Date: Thu, 29 Jan 2009 15:36:04 +0000
To: public-qt-comments@w3.org
Message-ID: <bug-6495-523@http.www.w3.org/Bugs/Public/>


           Summary: [UPD] Consistency within deleted subtrees
           Product: XPath / XQuery / XSLT
           Version: Candidate Recommendation
          Platform: PC
        OS/Version: Windows NT
            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

Certain combinations of updates - notably, creating two attributes with the
same name on the same element - are errors only by virtue of a rule that the
data model must satisfy all constraints described in the XDM spec.

It is not clear whether these consistency constraints apply

(a) in a subtree rooted at a node that is deleted in the course of the update

(b) in a subtree rooted at a node that is replaced in the course of the update.

For example, there is nothing to stop you creating two same-named attributes
for an element E that is itself the target of a delete or replace node
expression; it is not clear whether this is an error or not.

The answer depends on whether we believe that a node still exists after it has
been deleted or replaced. Clearly if it doesn't exist, then there can be no
consistency rules applied to it. Intuitively, we might think that a node
continues to exist after a replace operation but does not continue to exist
after a delete: however, those are intuitions based on the choice of English
keywords in the syntax, not on anything stated formally in the semantics.

Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
Received on Thursday, 29 January 2009 15:36:14 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:57:25 UTC