W3C home > Mailing lists > Public > public-qt-comments@w3.org > July 2005

[Bug 1551] New: [FS] editorial: 3.3.1 Kinds of Errors

From: <bugzilla@wiggum.w3.org>
Date: Tue, 12 Jul 2005 02:17:14 +0000
To: public-qt-comments@w3.org
Cc:
Message-Id: <E1DsAKg-00088o-43@wiggum.w3.org>

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

           Summary: [FS] editorial: 3.3.1 Kinds of Errors
           Product: XPath / XQuery / XSLT
           Version: Last Call drafts
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P2
         Component: Formal Semantics
        AssignedTo: simeon@us.ibm.com
        ReportedBy: jmdyck@ibiblio.org
         QAContact: public-qt-comments@w3.org


3.3.1 Kinds of Errors

"a static error (denoted by statError)"
    There's no need to introduce the symbol statError; it's never used.

"Non-type static errors"
    If 'static error' and 'type error' are distinct, then the "Non-type"
    is unnecessary.

"The [Functions and Operators] and [XQuery 1.0: A Query Language for XML]
documents raise specific error conditions, but because these error
conditions can be implemented in any way, we do not formalize them here."
    That doesn't sound very convincing. I mean, an XQuery processor can be
    "implemented in any way", but that doesn't stop you formalizing it.
    It seems plausible that you could write Dynamic Error rules that
    that raise specific errors, without over-constraining implementations.
    (E.g., 4.1.5 / DErr / rule 2 could raise err:XPTY0004 instead of just
    typeError.) I'm not saying you should do it, just that if you don't
    do it, you should have a better rationale.
Received on Tuesday, 12 July 2005 02:17:16 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:45:25 UTC