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

[Bug 24359] New: fn:error description lacks information about default arguments

From: <bugzilla@jessica.w3.org>
Date: Wed, 22 Jan 2014 14:27:25 +0000
To: public-qt-comments@w3.org
Message-ID: <bug-24359-523@http.www.w3.org/Bugs/Public/>
https://www.w3.org/Bugs/Public/show_bug.cgi?id=24359

            Bug ID: 24359
           Summary: fn:error description lacks information about default
                    arguments
           Product: XPath / XQuery / XSLT
           Version: Proposed Recommendation
          Hardware: PC
                OS: Windows NT
            Status: NEW
          Severity: normal
          Priority: P2
         Component: XPath 3.0
          Assignee: jonathan.robie@gmail.com
          Reporter: abel.braaksma@xs4all.nl
        QA Contact: public-qt-comments@w3.org

It appeared to me that fn:error [1] lacks a clear description of how omitted
arguments are filled.

We currently assume that fn:error(X) means that $description is filled (may be
filled) with the error description as defined in the XPath language for that
error, if the EQName resolves to an error in either the XPath language spec or
in a host language spec. This is in line with raising (known/defined)
exceptions in other languages. However, it is also possible that this is not
allowed and that $description must be empty in this case.

When the EQName doesn't resolve to a known error, we currently assume
$description to be the empty string. Though even in this case, perhaps an
implementation can define a predefined value for $description if the error is a
known implementation-defined error.

Likewise, for $error-object: is it implementation defined when omitted, or must
it be the empty sequence?

I think allowing implementations some freedom for filling $description and
$error-object can be beneficial for users.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
Received on Wednesday, 22 January 2014 14:27:27 UTC

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