- From: <bugzilla@wiggum.w3.org>
- Date: Tue, 12 Jul 2005 02:17:14 +0000
- To: public-qt-comments@w3.org
- Cc:
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