[Bug 3796] [UPDUseCases] Clarify how application constraints raise dynamic errors

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

           Summary: [UPDUseCases] Clarify how application constraints raise
                    dynamic errors
           Product: XPath / XQuery / XSLT
           Version: Working drafts
          Platform: PC
        OS/Version: All
            Status: NEW
          Severity: minor
          Priority: P4
         Component: Update Facility Use Cases
        AssignedTo: andrew.eisenberg@us.ibm.com
        ReportedBy: rpbourret@rpbourret.com
         QAContact: public-qt-comments@w3.org


Relational queries 8 and 9 (1.1.4.8 and .9) state that:

"An application constraint requires that no bid be placed on an item which was
not previously registered in the database. ... This update violates an
application constraint. Therefore, its execution raises a dynamic error ..."

It is not clear how an application constraint can cause a dynamic error to
occur, as there does not appear to be any way for XQuery to know that this
constraint exists.

I suspect that what is meant is that there is a referential integrity
constraint in the database that is violated by the query, that the database
reports this error to the XQuery processor, and that the XQuery processor
raises this as an implementation-defined dynamic error.

If this is the case, then:

a) Please clarify. For example, state that the query violates a constraint in
the underlying database. (The term "application constraint" is misleading, as
it is reasonable to assume that the application is the piece of software that
invokes the XQuery processor, rather than the combination of this software and
the database. In this case, an application constraint is enforced at a higher
level than XQuery, so XQuery won't know about it unless it is part of the query
itself.)

b) Please modify the description of the data to state that such a constraint
exists. Although it is implied that unique and foreign key constraints exist on
the tables, this is never stated.

Received on Wednesday, 4 October 2006 18:03:37 UTC