- 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