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


Tomas Mecir wrote:
> Definitely recommend certain parts of "user interface", ...
> 
> Note that this is not really user interface - user interface are
> dialogs and widget placement and such. This is about formula syntax,
> as perceived by the user.

I do think that SUM(A1:B3) vs SUM(A1;B3) is just user interface.

I think that adding this to the spec will be unnecessary work and it'll 
only increase the barrier for adoption. Here are some ideas:

OPTION 1: Require UI for (say) levels greater than 2.
OPTION 2: Have to types of compliance, or two specs. One for the format 
and one for UI.

I understand the desire to have a similar UI in different applications, 
but it's not the role of the format to impose this. It really isn't. I 
should be able to use BobOffice to write SUM(A1:B3) and give it to you 
to open in AliceOffice which uses SUM(A1;B3) and have it work 
transparently. That's the goal, IMO.


> I do not understand the difficulty in creating formulas - we write
> them to the wiki as plain-text, right ? Not maths notation for the
> most part. Or do you speak about the definitions of what the functions
> should compute ? Can't we use external references or images, in that
> case ?

I think David wants to write (sat) '\int \frac{x^2, x+1} dx' and have 
the wiki produce a nice-looking integral.

> Constraints should be high - that's what this is about. If things are
> too loose, there's no interoperability, because results differ.

+1

> Lowering constraints as low levels is fine, but the highest level
> should be as strict as reasonably possible.

I'm not too eager to have low constraints at low levels. I think low 
levels should just have fewer formulas. I also think this is important. 
A level 1 compliant file should also be level 2 compliant, and so on. 
Like this:

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.

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]