Subject: Re: [office] Question on implementation-defined - part 4 - formulas
The formula description describe the behaviour of a conformant OpenDocument Formula Evaluator evaluator, not of a conformant document. See 2.3.1.
We are using constraints to simplify the presentation but the "shall" is intended to specify a conformance requirement (for the evaluator, not the document).
We are using constraints since for the evaluation of most functions, the statement "If a constraint is not met, the function/operator shall return an Error." applies.
There are some functions were this is not the case, for example for BIN2DEC where the exception is that for an empty string (clearly in violation of the constraint) the evaluator shall return and error or 0. (And it is implementation defined whether this evaluator will always return 0 or always an error).
There are other places with similar exception language, for example in 5.12: "Functions shall propagate Errors unless stated otherwise." ISERROR and ISERR do not propagate errors.
Thanks for pointing me to 6.2. Maybe Iâm getting hung up on terminology here, butâ
If the definition of a constraint is not intended to specify a conformance requirement, the use of âshallâ is bothering me. In 1.2 Terminology it is stated clearly that the use of âshallâ is to be interpreted âas described in Annex H of the ISO/IEC Directivesâ.
I have not been able to find a copy of the 5th edition of the ISO/IEC Directives Part 2, which is the edition listed in the Normative References. The current edition of Part 2 is the 8th edition and doesnât contain an Annex H. I have been able to access an online copy of the 6th edition on the CEN website, which has an Annex H âVerbal forms for the _expression_ of provisionsâ, which I presume to be the same as was in the 5th edition. Here the verbal form âshallâ is specified in Table H.1,Â which is preceded by the following text: âThe verbal forms shown in Table H.1 shall be used to indicate requirements strictly to be followed in order to conform to the document and from which no deviation is permitted.â The current edition is organized differently, but specifies much the same in Table 3 and clause 3.3.3.
I presume that Keyword Guidelines for OASIS Specifications and Standards, Appendix B, specifies the use of âshallâ as currently interpreted by OASIS, and therefore as assumed to apply to ODF 1.3. This defines the use of âshallâ in the following terms: âto indicate requirements strictly to be followed in order to conform to the standard and in which no deviation is permitted.â This is clearly consistent with the ISO/IEC Directives.
It would therefore seem that the use of âshallâ in definitions of function constraints is problematic.
On 2020-10-31 2:11 p.m., Francis Cave wrote:
In my opinion the standard does not have to say anything about an empty string, because the Constraints section says that X âshall contain at least one binary digitâ. If the document is a conforming document, X will not be empty. If one goes down the path of defining how consumers should process non-conforming documents, that way madness lies, in my opinion. The spec should only specify how to handle conforming documents. All bets are off otherwise.
This has nothing to do with "conforming documents". Violating a constraint does not make the document non-conforming. See 6.2:
Constraints: A description of constraints, in addition to the constraints imposed by the parameter
types. If there are no additional constraints beyond those imposed by the parameter types, this is
"None". If a constraint is not met, the function/operator shall return an Error unless otherwise noted.
The alternative is to change the constraints to allow X to be an empty string, in which case it then makes sense to say how this should be handled.
It seems like awkward wording but off-hand I don't know of a better suggestion. Will think about it.
Hope you are having a great weekend!
On 10/31/20 2:57 PM, andreas.guelzow wrote:
The intention is that there are 2 possible values and the implementation should decide and define which of these two values will be returned.
Sent from my Samsung Galaxy smartphone.
-------- Original message --------
From: Patrick Durusau <firstname.lastname@example.org>
Date: 2020-10-31 12:12 (GMT-07:00)
To: ODF TC List <email@example.com>
Subject: [office] Question on implementation-defined - part 4 - formulas
I'm compiling a spreadsheet of all instances of
implementation-defined/dependent and ran into an odd case in part 4:
If any digits are 2 through 9, an evaluator shall return an Error. It is
implementation-defined what happens if an evaluator is given an empty
string; evaluators may return an Error or 0 in such cases.
Notice that we say "implementation-defined," but then immediately follow
with: *may* return an Error or 0 in such cases.
If we mean, "implemention-defined," isn't that all we should say and stop?
Or, are we using "implementation-defined" in a common sense and then
specifying with "may," the possible options to return?
This happens more than once in part 4.
Before I create a lot of needless JIRA issues, wanted to check with the TC.
Hope everyone is having a great weekend!
Technical Advisory Board, OASIS (TAB)
Editor, OpenDocument Format TC (OASIS), Project Editor ISO/IEC 26300
Co-Editor, ISO/IEC 13250-1, 13250-5 (Topic Maps)
Another Word For It (blog): http://tm.durusau.net
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail.Â Follow this link to all your TCs in OASIS at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php--Patrick DurusauTechnical Advisory Board, OASIS (TAB)Editor, OpenDocument Format TC (OASIS), Project Editor ISO/IEC 26300Co-Editor, ISO/IEC 13250-1, 13250-5 (Topic Maps)ÂAnother Word For It (blog): http://tm.durusau.netHomepage: http://www.durusau.netTwitter: patrickDurusau