- From: <bugzilla@jessica.w3.org>
- Date: Thu, 14 Mar 2013 09:35:39 +0000
- To: public-qt-comments@w3.org
https://www.w3.org/Bugs/Public/show_bug.cgi?id=21284 --- Comment #1 from Michael Kay <mike@saxonica.com> --- The general statement is 9.8.4 is complemented by more specific statements for particular errors. For example 9.8.4.1 says A dynamic error is reported [err:FOFD1340] if the syntax of the picture is incorrect. For calendar, language, and place, I agree the error handling is a little unclear. (A) For $language, we say: The $language argument specifies the language to be used for the result string of the function. The value of the argument *must* be either the empty sequence or a value that would be valid for the xml:lang attribute (see [XML]). but then we say: If the $language argument is omitted or is set to an empty sequence, or if it is set to an invalid value or a value that the implementation does not recognize, then the processor uses the default language defined in the dynamic context. So the *must* is a rather weak *must*, and perhaps should be a *should*. (B) For $calendar, we say it *must* be a valid lexical QName, but define no error condition if it is not. B1. Where we allow lexical QNames to be constructed dynamically as strings, we normally have extended the spec to allow an EQName, and we should probably do so here. B2. We hint, but do not spell out, that implementation-defined calendars should be in a vendor namespace. We should probably say this explicitly. Apart from the requirement to be a valid lexical QName, there are currently no errors that result from using an unknown calendar. We could, but don't currently, say that if the name is in no namespace then it must be one of those listed. (C) For $place, there appear to be no error conditions: any string is accepted. -- You are receiving this mail because: You are the QA Contact for the bug.
Received on Thursday, 14 March 2013 09:35:46 UTC