- 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