- From: Andrew Eisenberg <andrew.eisenberg@us.ibm.com>
- Date: Mon, 19 Jan 2004 08:05:17 -0500
- To: public-qt-comments@w3.org
- Cc: Don Chamberlin <chamberl@almaden.ibm.com>
- Message-ID: <OF4E2B39E1.2F2B3754-ON85256E20.0019F591-85256E20.0047E4F6@us.ibm.com>
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