OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

office-formula message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [office-formula] Key Issues


Hi David,

On Sat, Feb 25, 2006 at 14:59:59 -0500, David A. Wheeler wrote:

> * Should we use OpenFormula as a base specification?

Yes, +1

> * Schedule: We need to define syntax, then semantics.  Proposal: Draft
> syntax defined by start+2 months; final syntax/semantics (inc.
> function definitions) defined by start+6 months.

I'm not confident with scheduling big blobs in terms of months. Do we
need a schedule that encompasses the whole thing?

> Should "start" be March 2?

Ok.

> * Issue: Goals/range.  Rob Weir and David A. Wheeler both want it to
> support both limited resources (e.g., tiny PDAs) and massive
> capabilities.  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?

It seems we already have a problem with the definition of what a level
would be.. let's agree that we need some sort of levels, be it levels or
packages or levels+packages.

> ** If we have levels, must define the levels.  Discuss briefly whatwe
> want, what are the levels.  Can we try to create rough resolution by
> March 17 on the levels, if we agree to define levels?

Should be possible.

> * Scope: Define this specification as ONLY an interchange format, and
> at most RECOMMEND user interface issues?

Leave out UI completely and have this ONLY be a spec of file format.

> * Test cases: Should we include test cases in the spec?

Test cases are fine to accompany a spec as an implementation guideline
and source of examples, but I doubt they should be part of the
specification itself, IMHO. Or in other words: should test cases really
be normative?

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

Yes.

> 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.

Does MoinMoin support some sort of file uploads and links to it? We
could create formulas using OOoMath then, to be included later in the
ODF document.

> * Syntax.  All ODF-supporting spreadsheets support the basic
> OpenOffice.org syntax, e.g., [.B4].  Wheeler proposes that we use the
> OpenOffice.org syntax as a starting point; OpenFormula did this.
> However, we may need to add to the syntax as necessary (e.g., to
> support the cell union infix operator, empty parameters, or inline
> arrays).

I don't get that. How is it related/opposed to the ODF [.B4] syntax?

> * 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 suggest to not merge that with the levels as currently defined in the
OpenFormula approach. To me, a separate category for "implicit
conversions" would be a better approach. This could result in 3-4 levels
times 2-3 conversion categories though, giving up to 12 permutations, so
drawing a line in between would be recommendable.

> * 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.

Later..

  Eike


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]