Re: [office-formula] Portable "documents"

[Eike Rathke <erack@sun.com>]

Hi,

I think I waded through this thread the third time by now, and the
solution Michael proposed seems most appropriate to me. With some
obstacles maybe.

On Wednesday, 2009-12-16 10:33:26 +0100, Michael Brauer wrote:

> 1. In a first pass the specification is adapted to make use of the new
> performance targets the SC has agreed. Essentially this means that terms
> like "document" are replaced with "expressions" and terms like
> "implementation" and "program" are replaced with "evaluator". This may  
> require small adaptations of the language (in particular if must is  
> replaced by shall, etc. at the same time), but should not change the  
> constrains themselves.

Be careful in replacing "document" with "expressions". Expression is
a defined term. Example from section 3.3.3 Date and DateTime:

| Portable documents shall not include date calculations that require the
| incorrect assumption that 1900 was a leap year.

In an implementation that erroneously implemented 1900 to be a leap year
we may have:

Cell A1 contains the date 1900-02-28, the expression in A2 =A1+1 results
in the date 1900-02-29, the expression in A3 =A2+1 results in the date
1900-03-01. It is not the expressions them self that make the incorrect
assumption, but they yield different dates in an implementation that
does not implement the 1900 leap year bug. It is how the expressions are
used in the document.


> 2. In a 2nd pass, or in parallel, the portable document statements are
> turned into notes, but without rephrasing them or moving them.

I don't know how this could be done in parallel with #1, but otherwise
yes.


> 3. In a third pass, the notes are checked individually. If they can be
> turned into statements what is implementation or undefined behavior of
> evaluators, they are rephrased accordingly. If they can be turned into
> statements what is optional behavior of an evaluator, the are also
> rephrased accordingly. And if both is not possible, they are kept as is.

Rephrased and turned into normative statements and removed from the
notes, as Patrick noted.


> [... behaviors for evaluators ...]
>> I wonder if an approach like that might result in a tighter 
>> specification?  In other words, rephrase all portability constraints as 
>> positive statements about undefined, implementation-defined and  
>> implementation-dependent behaviors?
>
> This goes into the same direction as I have suggested a few days ago.
> So, yes, this may be a reasonable approach, except that I think there
> are more options to rephrase statements about portable document than
> turning them into statements what is undefined, implementation defined
> or implementation dependent. Another option is to declare behavior to be
> optional. For instance, while the size of an integer is undefined, there
> may be a minimum size that all evaluators shall support. But evaluators
> may support larger integer values. If they do so, the result is well
> defined. Only only does not know whether larger values are supported.

Optional may work in some cases, but I think in most it will not.
Supporting a larger range of values would be optional, but we don't have
that many cases. The question whether a boolean type is converted to
a number in a NumberSequence is not optional. It is
implementation-defined and affects each function that expects
a NumberSequence as parameter.

  Eike

-- 
Automatic string conversions considered dangerous. They are the GOTO statements
of spreadsheets.  --Robert Weir on the OpenDocument formula subcommittee's list.

PGP signature