OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

office-formula message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: Re: [office-formula] On "portability" (resend)


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".

Best regards


Michael Brauer, Technical Architect Software Engineering
Sun Microsystems GmbH             Nagelsweg 55
D-20097 Hamburg, Germany          michael.brauer@sun.com
http://sun.com/staroffice         +49 40 23646 500

Sitz der Gesellschaft: Sun Microsystems GmbH, Sonnenallee 1,
	   D-85551 Kirchheim-Heimstetten
Amtsgericht Muenchen: HRB 161028
Geschaeftsfuehrer: Thomas Schroeder, Wolfgang Engels, Wolf Frenkel
Vorsitzender des Aufsichtsrates: Martin Haering

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]