Re: [office-formula] On "portability"

[Patrick Durusau <patrick@durusau.net>]

Michael,

Comments below:

Michael Brauer - Sun Germany - ham02 - Hamburg wrote:
> Hi,
>
> Am 08.12.09 22:31, Patrick Durusau schrieb:
>> Greetings!
>>
>
>> Here's my question: Why not simply state those parameters that will 
>> influence results and then say: The results defined by OpenFormula 
>> are based on environmental conditions 1....n. If your environment 
>> does not meet these conditions or you have extensions to OpenFormula, 
>> then your formulas may have behaviors that are not defined by 
>> OpenFormula. If that is an issue for you, don't do that.
>
> This seems to be a solution to me at least for the "portable 
> constrains" we find starting with chapter 5. It is my understanding 
> that these "portable constrains" indeed define the value range for 
> which a function or operations calculates to a well-defined result. 
> For instance: 5.6.2 BITAND says:
>
> "Portable Constraints: INT(X)=X, INT(Y)=Y, 0 <= X < 2^48, 0 <= Y < 2^48"
>
> I'm not sure, but since we also use the term "portable document", my 
> understanding is that this right now defines a constrain that portable 
> document must meet. But one may also read this as: These are the 
> parameter values for which an evaluator shall return a well defined 
> result. This turns the constrains from constrains for documents (or 
> expressions) into constrains for evaluators. But actually, this may be 
> better approach: An expression is portable if and only if it contains 
> only expressions for which we know that all evaluators calculate the 
> same result. So, the "portable constrains" are actually constrains for 
> evaluators. They must calculate the "correct" result for expressions 
> that meet these constrains. If authors consider these constrains in 
> the expressions they add to document, they get portable documents.
>
> There may be another reason why it may be reasonable to consider the 
> "portable constrains" to be constrains for evaluators: The 
> "Expression" conformance clause is about the syntax only. On the 
> syntax level, one cannot verify whether a parameter of a function 
> meets a particular constrains, because unless the parameter is a 
> constant, its value is only known when the expression is evaluated.
>
>
> In chapters 1 to 4 the situation is a little bit different, the term 
> "portable" is here sometimes used in connections with recommendation 
> how authors create portable documents. For instance, in section 3.3.3 
> Date and DateTime, we find:
>
> "Portable spreadsheet files shall not assume any particular epoch 
> values."
>
> "Portable documents shall not include date calculations that require 
> the incorrect assumption that 1900 was a leap year. Portable documents 
> shall not assume that negative date values are impossible (many 
> implementations use negative dates to represent dates before the epoch)."
>
> These seem to be guidelines for authors. They cannot be tested on the 
> syntax or "expression conformance" level, and it may even be difficult 
> to test them on the "evaluator conformance" level . My suggestion 
> would be turn them into notes which provide guidelines for authors.
>
> Other occurrences of "portable document" in chapters 1 to 4 however 
> may be turned into requirements for evaluators, too. For instance 
> 4.11.1 says:
>
> "Portable documents should limit the names of their identifiers to 
> only (Unicode) letters, underscores, and digits, not including 
> patterns that look like cell references or the words True or False."
>
> This could be read as: "Evaluators shall support identifiers that 
> consist of (Unicode) letters, underscores, and digits unless the 
> identifier matches the syntax of a cell reference, or contains the 
> terms "True" or "False".
>
Err, on that last point, wasn't the intent of the original text to 
exclude "patterns that look like cell references or the words True or 
False?"

That is to say that identifiers should not "look like" (I can hear the 
UK comment even as I say that) cell references or be the words True or 
False?

Which I would re-word to read:

Identifiers shall consist of Unicode (do you want character classes 
here?, underscore is only one character) characters and shall not match 
the syntax of a cell reference and shall not be the words True or False.

True that people can choose to use other identifiers but then they are 
not conforming to OpenFormula.

****

Back to main issue:

To no small degree, I think OpenFormula needs to be less descriptive and 
more prescriptive, what it nows calls "portable." Yes, there will be 
behaviors beyond that which we define but that will always be true. If a 
user goes beyond the standard, say they have identifiers written in some 
dialect of InterGalactic, they aren't going to have much success sharing 
their spreadsheets. But it will also be the case that they did not 
conform to OpenFormula so they were on notice that would be the case.

Standards, for good or ill, are supposed to be prescriptive of a limited 
range of behaviors. That doesn't mean that there are not behaviors 
beyond what the standard describes, there always are, but those are not 
the concern of the standard.

I like your idea of saying that OpenFormula provides definite results 
only under a defined set of conditions. I think that will give us the 
ability to make explicit assumptions about the operating environment and 
reduce the number of asides and exceptions.

Hope you are having a great day!

Patrick

> Best regards
>
> Michael
>
>
>

-- 
Patrick Durusau
patrick@durusau.net
Chair, V1 - US TAG to JTC 1/SC 34
Convener, JTC 1/SC 34/WG 3 (Topic Maps)
Editor, OpenDocument Format TC (OASIS), Project Editor ISO/IEC 26300
Co-Editor, ISO/IEC 13250-1, 13250-5 (Topic Maps)