[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [office-formula] Key Issues
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?
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]