Re: [office-formula] Key Issues

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

David A. Wheeler wrote:
> * Should we use OpenFormula as a base specification?

I vote +1

> * Schedule: We need to define syntax, then semantics.

I have no idea of what a reasonable timeframe is. I'll go with whatever 
most people want.

> * Issue: Goals/range.  Rob Weir and David A. Wheeler both want
> it to support both limited resources (e.g., tiny PDAs) and
> massive capabilities.

Add Daniel to that list. The role of small embedded devices will only 
increase with time.

>  Yet if everything is optional, no one will know what is supported,
> and users won't have real interoperability.  A solution for this
> problem is to define "levels" (OpenFormula did this).  Do we agree
> that we should have multiple levels?

I sure can't see any other option. I do have a question. Based on the 
OpenFormula experience, would you say that level 1 would still be large 
enough to be useful?

The only drawback of levels is that we might see spreadsheets complying 
to level 1 only and then saying to their customers "we're compliant". 
For this reason, I'd like level 1 to be good and meaningful for the 
average user.

> ** If we have levels, must define the levels.  Discuss briefly
> whatwe  want, what are the levels.

I don't know about levels >1 but I think that it's important that level 
1 be complete enough to guarantee interoperability for most users. I 
wonder, is this goal compatible with the goal of making level 1 suitable 
for tiny PDAs?

> Can we try to create rough  resolution by March 17 on the levels,

Sure, why not.

> * Scope: Define this specification as ONLY an interchange format
>, and at most RECOMMEND user interface issues?
>  Wheeler recommends defining the spec as ONLY an interchange format.

I agree.
* As a developer, I don't want the spec telling me how to do UI. That is 
none of the spec's business.
* UI considerations may be incompatible with interoperability goals.
* Adding UI requirements will only create a gratuitious barrier. No one 
will change their UI just to comply with OpenDocument. Even I might not.
* UI considerations would make the spec much larger for no benefit that 
I can see.
* OpenDocument doesn't include UI.

> * Test cases: Should we include test cases in the spec?
> Wheeler STRONGLY recommends it.  Including test cases
> eliminates many problems of ambiguity in the text;

I'd say that this is important for a formula spec. Not just because of 
ambiguity, but because it just makes it easier to implement right. I can 
run a test suite faster than I can read 20 pages of text.

test cases == lower barriers to adoption

Isn't this one of the reasons why OpenDocument uses RelaxNG instead of 
DTD? Because RelaxNG allows you to make a more precise automated test?

> Wheeler  believes it is VERY difficult to write unambiguous text,

Mathematical information is easier to convey in mathematical language.

Formula spec == mathematical information.
Test cases == mathematical language.

> * Discuss use of Wiki.  Do we want to try to put stuff in a Wiki
> and LATER transition text to ODF? Transition to an ODF document NOW?  

We have to use the OASIS wiki, right? Can non-OASIS people use the OASIS 
wiki?

> One issue: The Wiki must be MoinMoin, and it's unclear if OASIS will
> install the MoinMoin math formula support.  Without formula support,
> formulas may be harder to create.

Formulas are hard to create with OpenDocument tools also. And I don't 
fancy using LaTeX for the spec.

> * Syntax...  Wheeler proposes that we use the OpenOffice.org
> syntax as a starting point;

Sure. Why not.

> * Semantics.  How strongly should we constrain semantics,
> and how should we determine them?  For example, different
> applications use different rules for automatic conversion
> from text to number (e.g., "3"+2).  Some want very specific
> semantics defined; others want it looser.  OpenFormula split
> the difference by allowing much variance at levels 1 and 2,
> but having stricter semantics at 3.  We could avoid it
> (leave some semantics undefined or loosely defined), use
> levels, create a separate category ("strict" vs. "loose"
> semantics), or something else.

I don't like the "strict" vs "loose" idea. I'm ok with the levels idea, 
but in general I'd prefer to define scemantics strictly.

poor scemantics == poor interoperability

If you send me an OpenDocument spreadsheet, I should be able to look at 
the cell labeled "total" and see the same value that you see. If I 
don't, we don't have interoperability.

I don't think that strict scemantics have to be a problem as long as the 
formula spec also provides explicit type conversion functions. Consider 
this example:

* In BobOffice "3"+3 is 6.
* In AlliceOffice "3"+3 is an error.
* Take this spreadsheet in BobOffice

      A
1  "3"
2   3
3  =A1+A2

When I *save* this spreadsheet in BobOffice, the cell A3 could be saved as:

=StringToNum([.A1])+A2


Now, when I open the file in AliceOffice, AlliceOffice sees the explicit 
conversion and gives me the appropriate result.

CONSEQUENCES:

* Now we have interoperability.
* BobOffice doesn't have to change the UI.
* But BobOffice and AliceOffice must implement a StringToNum() function.


> * Complex Numbers.  We don't have time to go into it at the
> beginning of this process, but although many implementations
> support complex numbers, their support is really HORRIBLE to
> users.  Later on we'll need to determine what we should do
> about them.

Ok.

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?