Re: [office-formula] Key Issues

[Daniel Carrera <daniel.carrera@zmsl.com>]

Tomas Mecir wrote:
> Hmm, the user-perceived format would usually be pretty similar to the
> storage format - because there's no reason why not.

I don't see any reason why the UI must match the storage format, and I 
can think of reasons why it shouldn't. The requirements are different.

* In a UI format you want to avoid verbose syntax, and you want syntax 
that might feel natural. For example, "3,25" vs "3.25" depending on 
locale. A PDA without a keyboard may find it cumbersome to require users 
to put a : or a ; between function arguments when a space will do (e.g. 
=SUM(A1 B2 C3)

* In a storage format you want *precision* and unambiguity. You want to 
have things like

=SUM(StringToNum([.A2]);[.B3]);

Which would be cumbersom for someone to type (esp on a PDA!).


> Otherwise, it would be plain impossible to create test-cases at all !

I don't see that at all. We create a file and specify what the output of 
the spreadsheet should be. For example, we would specify that columns D4 
to D23 must say "Pass" without specifying the UI formula syntax.


> Just imagine - we make a test-case, say,
> that SUM(A1:B3) with certain values in A1..B3 should provide
> such-and-such result. Someone decides to try it out on BobOffice, but
> fails - BobOffice requires you to use a different syntax. Not very
> inter-operable, mind you.

No no no. Don't confuse the UI with the format.

Suppose the spec says SUM(A1:B3) should add the values in A1..B3 and Bob 
decides that BobOffice will use the SUM(A1;B3) syntax. This is what happens:

* Alice saves a file. The FILE contains the string 'SUM(A1:B3)' as per 
the spec.
* Bob opens the file. The OpenDocument filter of BobOffice interprets 
the string 'SUM(A1:B3)' correctly and, at the UI level, shows it to Bob 
as 'SUM(A1;B3)' and computes the correct result.

Therefore, though AliceOffice and BobOffice have a different UI, both 
Bob and Alice can open the same file and get the same result.


>>level 1 < level 2 < level 3 < level 4
>>
>>Where < denotes "subset".
>>
>>Any file compliant with level n must also be compliant with level m for
>>all m > n. So a level m application can open all level n files with
>>level m reliability.
> 
> Yeah, that's what I mean. Lower requirements don't necessarily nullify
> this. For example, say, you require a level 2 implementation to hold
> that X/3*3 == X, but level 1 may differ by no more than 1e-15. Then a
> level 1 spreadsheet's result would be within the tolerance, or
> correct, but level 2's spreadsheet's result would always be correct -
> which meets the 1e-15 delta requirement.

Ok, I'm cool with level 1 having a different margin of error than level 
2. What I was worried about that a level 1 file might be an *invalid* 
file at level 2.

Cheers,
Daniel.
-- 
      /\/`) http://opendocumentfellowship.org
     /\/_/
    /\/_/ I'm not saying there should be a capital punishment for
    \/_/  stupidity, but why don't we just take the safety labels
    /     off of everything and let the problem solve itself?