This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
Problem raised by Paul J. Lucas today on public-qt-comments. On 14/03/2013 00:47, Paul J. Lucas wrote: > The XPath and XQuery Functions and Operators 3.0, section 9.8.4 says in part: > >> In general, the use of an invalid $picture, $language, $calendar, or $place argument results in a dynamic error. > > but it doesn't say which error code should be raised. So, which error should be raised? > > - Paul > > >
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.
Implemented the following changes: 1. In 9.8.4 last para, ("In general, the use of an invalid $picture, $language, $calendar, or $place argument results in a dynamic error.....") added the error reference err:FOFD1340, and the phrase "More detailed rules are given below." 2. For $language, in the para cited as (A) in comment 1, changed the "must" to "should". 3. For $calendar, we now say: The calendar value if present *must* be a valid _EQName_ [FOFD1340]. If it is a lexical QName then it is expanded into an expanded QName using the statically known namespaces; if it has no prefix then it represents an expanded-QName in no namespace. If the expanded QName is in no namespace then it *must* identify a calendar with a designator specified below [FOFD1340]. If the expanded QName is in a namespace then it identifies the calendar in an implementation-defined way. 4. For the $place argument, we add the sentence "If the value does not take this form, or if its value is not recognized by the implementation, then the default place defined in the dynamic context is used."
I have found a minor typo in the specification from 30 April 2013: "it must identifies". It occurs a second time in the checklist of implementation-defined features.
Thanks, fixed.