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