[XQuery] IBM-XQ-001 - changes to error QNames

Some members of NCITS H2, including IBM, are planning to propose the 
embedding of XQuery expressions within SQL statements in the next version 
of SQL/XML. This feature is made possible by the addition of an XML data 
type in SQL/XML:2003. In adding this feature, errors in the evaluation of 
an XQuery expression will need to be reflected in SQLSTATE values, which 
have the following description:

The character string value returned in an SQLSTATE parameter comprises a 
2-character class value followed by a 3-character subclass value, each 
with an implementation-defined character set that has a one-octet 
character encoding form and is restricted to <digit>s and <simple Latin 
upper case letter>s.

We suggest a small number of changes to XQuery to more easily support the 
reflection of XQuery errors in SQL. We believe that these changes will be 
helpful in the embedding of XQuery within other environments as well.


1. Ensure that the local part of QNames that are defined in XQuery use 
only 5 characters

Add a statement such as the following:

2.5.x Identifying Errors

The errors that are defined by this specification (indicated by "an error 
is raised: [...]") will use QNames with local parts that have the form 
XXYYY, where XX is one of "XP" or "XQ" and YYY consists of exactly 3 
characters that are digits.


2. Change the existing error QNames

Replace XP0xxx with XPxxx and XQ0xxx with XQxxx.


3. Define the "err:" namespace prefix

Choose a namespace URI that does not change from one version of XQuery to 
another.


4. Disallow error values that are the empty sequence

The evaluation of fn:error() and fn:error($arg), where $arg is the empty 
sequence, should have the effect of raising err:XQnnn (specific value to 
be assigned by the XQuery editors). This error would be defined as 
follows:

        XQnnn

        Unspecified dynamic error.

 
5. Make error values more regular

The fn:error function accepts an argument of type item()?. We suggest that 
all errors should be identified by QNames, possibly with an associated 
non-QName value. The means by which the non-QName value is provided to a 
host environment is implementation-dependent.

Specifically, when $arg is a value with a type other than xs:QName, then 
the evaluation of fn:error should have the effect of raising err:XQmmm. 
This error would be defined as follows:

        XQmmm 

        Unspecified dynamic error with non-QName value.


6. More clearly identify errors that are defined by implementations and 
users

We suggest that all errors reported to a host environment be defined in 
this specification. Errors raised by an implementation or a user with 
QName values would be identified by a standard error with an associated 
QName value. The means by which the QName value is provided to a host 
environment is implementation-dependent.

Specifically, when $arg is a value with type xs:QName, but it is not a 
QName defined by this specification, then the evaluation of fn:error 
should have the effect of raising err:XQrrr. This error would be defined 
as follows: 

        XQrrr 

        Implementation-defined or user-defined error.

7. Change the error QNames defined in F&O

Replace all of the QNames in Annex D, Error Summary (Non-Normative), with 
QNames of the form err:XFxxx.


8. Make the error QNames Normative in F&O

Change the title of Annex D from " Error Summary (Non-Normative)" to just 
" Error Summary".

Add the following sentence to the beginning of this annex:

        The error text provided with these errors is non-normative.


8. Define error QNames in Serialization

Serialization states in numerous places, starting with Section 2, 
Serializing Arbitrary Data Models, bullet 2, "It is a serialization error 
if ..."

Like XQuery and F&O, QNames should be associated with these errors. These 
QNames should have the form err:XSxxx.


                                                        -- Andrew

--------------------
Andrew Eisenberg
IBM
5 Technology Park Drive
Westford, MA  01886

andrew.eisenberg@us.ibm.com
Phone: 978-399-5158    Fax: 978-399-5117

Received on Monday, 19 January 2004 08:05:27 UTC