OASIS Open Document Format for Office Applications (OpenDocument) TC

 View Only
  • 1.  Question on implementation-defined - part 4 - formulas

    Posted 10-31-2020 18:13
    Greetings! I'm compiling a spreadsheet of all instances of implementation-defined/dependent and ran into an odd case in part 4: 6.19.4 BIN2DEC ... 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. Thanks! Hope everyone is having a great weekend! Patrick -- Patrick Durusau patrick@durusau.net 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 Homepage: http://www.durusau.net Twitter: patrickDurusau


  • 2.  Re: [office] Question on implementation-defined - part 4 - formulas

    Posted 10-31-2020 18:54
    Hi Patrick, I suggest to use a consistent structure. In section 6.13.16 Conversion to TimeParam, item Logical you find: Logical, the result is implementation-defined, either a Number or Error Such structure can be used here too: If X is an empty string, the result is implementation-defined, either 0 or an Error. Kind regards Regina Patrick Durusau schrieb am 31-Oct-20 um 19:12: Greetings! I'm compiling a spreadsheet of all instances of implementation-defined/dependent and ran into an odd case in part 4: 6.19.4 BIN2DEC ... 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. Thanks! Hope everyone is having a great weekend! Patrick


  • 3.  RE: [office] Question on implementation-defined - part 4 - formulas

    Posted 10-31-2020 18:57
    The intention is that there are 2 possible values and the implementation should decide and define which of these two values will be returned. Andreas Sent from my Samsung Galaxy smartphone.


  • 4.  Re: [office] Question on implementation-defined - part 4 - formulas

    Posted 10-31-2020 19:03
    Thanks! 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! Patrick 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. Andreas Sent from my Samsung Galaxy smartphone.


  • 5.  RE: [office] Question on implementation-defined - part 4 - formulas

    Posted 10-31-2020 20:12
    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.   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.   Francis     From: office@lists.oasis-open.org <office@lists.oasis-open.org> On Behalf Of Patrick Durusau Sent: 31 October 2020 19:03 To: andreas.guelzow <andreas.guelzow@concordia.ab.ca>; ODF TC List <office@lists.oasis-open.org> Subject: Re: [office] Question on implementation-defined - part 4 - formulas   Thanks! 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! Patrick 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. Andreas         Sent from my Samsung Galaxy smartphone.    


  • 6.  Re: [office] Question on implementation-defined - part 4 - formulas

    Posted 10-31-2020 20:33
    HI, 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. Andreas 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. Francis From: office@lists.oasis-open.org <office@lists.oasis-open.org> On Behalf Of Patrick Durusau Sent: 31 October 2020 19:03 To: andreas.guelzow <andreas.guelzow@concordia.ab.ca> ; ODF TC List <office@lists.oasis-open.org> Subject: Re: [office] Question on implementation-defined - part 4 - formulas Thanks! 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! Patrick 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. Andreas Sent from my Samsung Galaxy smartphone.


  • 7.  RE: [office] Question on implementation-defined - part 4 - formulas

    Posted 11-01-2020 00:09
    Hi Andreas   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 5 th 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 8 th edition and doesn t contain an Annex H. I have been able to access an online copy of the 6 th 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 5 th 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.   Kind regards,   Francis     From: Andreas J Guelzow <andreas.guelzow@concordia.ab.ca> Sent: 31 October 2020 20:33 To: Francis Cave <francis@franciscave.com>; 'Patrick Durusau' <patrick@durusau.net>; 'ODF TC List' <office@lists.oasis-open.org> Subject: Re: [office] Question on implementation-defined - part 4 - formulas   HI, 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. Andreas   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.   Francis     From: office@lists.oasis-open.org <office@lists.oasis-open.org> On Behalf Of Patrick Durusau Sent: 31 October 2020 19:03 To: andreas.guelzow <andreas.guelzow@concordia.ab.ca> ; ODF TC List <office@lists.oasis-open.org> Subject: Re: [office] Question on implementation-defined - part 4 - formulas   Thanks! 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! Patrick 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. Andreas         Sent from my Samsung Galaxy smartphone.    


  • 8.  Re: [office] Question on implementation-defined - part 4 - formulas

    Posted 11-01-2020 00:53
    Hi Francis, 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. Andreas On 2020-10-31 6:08 p.m., Francis Cave wrote: Hi Andreas 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 5 th 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 8 th edition and doesn t contain an Annex H. I have been able to access an online copy of the 6 th 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 5 th 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. Kind regards, Francis From: Andreas J Guelzow <andreas.guelzow@concordia.ab.ca> Sent: 31 October 2020 20:33 To: Francis Cave <francis@franciscave.com> ; 'Patrick Durusau' <patrick@durusau.net> ; 'ODF TC List' <office@lists.oasis-open.org> Subject: Re: [office] Question on implementation-defined - part 4 - formulas HI, 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. Andreas 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. Francis From: office@lists.oasis-open.org <office@lists.oasis-open.org> On Behalf Of Patrick Durusau Sent: 31 October 2020 19:03 To: andreas.guelzow <andreas.guelzow@concordia.ab.ca> ; ODF TC List <office@lists.oasis-open.org> Subject: Re: [office] Question on implementation-defined - part 4 - formulas Thanks! 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! Patrick 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. Andreas Sent from my Samsung Galaxy smartphone.


  • 9.  RE: [office] Question on implementation-defined - part 4 - formulas

    Posted 11-01-2020 11:41
    Hi Andreas   Thanks for putting me straight on this. I had dived down a rabbit-hole and lost my sense of direction! I had forgotten that Part 4 is mainly concerned with evaluator (process) conformance, not document conformance. In that case I gladly stand corrected.   I think that the wording could be improved in chapter 2 to make this clearer, but any improvements would be editorial.   Kind regards,   Francis       From: office@lists.oasis-open.org <office@lists.oasis-open.org> On Behalf Of Andreas J Guelzow Sent: 01 November 2020 00:53 To: Francis Cave <francis@franciscave.com>; 'Patrick Durusau' <patrick@durusau.net>; 'ODF TC List' <office@lists.oasis-open.org> Subject: Re: [office] Question on implementation-defined - part 4 - formulas   Hi Francis, 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. Andreas On 2020-10-31 6:08 p.m., Francis Cave wrote: Hi Andreas   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 5 th 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 8 th edition and doesn t contain an Annex H. I have been able to access an online copy of the 6 th 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 5 th 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.   Kind regards,   Francis     From: Andreas J Guelzow <andreas.guelzow@concordia.ab.ca> Sent: 31 October 2020 20:33 To: Francis Cave <francis@franciscave.com> ; 'Patrick Durusau' <patrick@durusau.net> ; 'ODF TC List' <office@lists.oasis-open.org> Subject: Re: [office] Question on implementation-defined - part 4 - formulas   HI, 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. Andreas   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.   Francis     From: office@lists.oasis-open.org <office@lists.oasis-open.org> On Behalf Of Patrick Durusau Sent: 31 October 2020 19:03 To: andreas.guelzow <andreas.guelzow@concordia.ab.ca> ; ODF TC List <office@lists.oasis-open.org> Subject: Re: [office] Question on implementation-defined - part 4 - formulas   Thanks! 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! Patrick 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. Andreas         Sent from my Samsung Galaxy smartphone.    


  • 10.  Re: [office] Question on implementation-defined - part 4 - formulas

    Posted 10-31-2020 18:58
    Hi Patrick, Patrick Durusau schrieb am 31-Oct-20 um 19:12: Before I create a lot of needless JIRA issues, wanted to check with the TC. For me it look more like an editorial problem, which should be tracked not in JIRA but in GitHub. Kind regards Regina


  • 11.  Re: [office] Question on implementation-defined - part 4 - formulas

    Posted 10-31-2020 19:04
    Regina, Thanks! Github sounds like the better place for it. Hope you are having a great weekend! Patrick On 10/31/20 2:58 PM, Regina Henschel wrote: > Hi Patrick, > > Patrick Durusau schrieb am 31-Oct-20 um 19:12: >> >> Before I create a lot of needless JIRA issues, wanted to check with >> the TC. >> > > For me it look more like an editorial problem, which should be tracked > not in JIRA but in GitHub. > > Kind regards > Regina > > --------------------------------------------------------------------- > 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 Durusau patrick@durusau.net 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 Homepage: http://www.durusau.net Twitter: patrickDurusau