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] Goals/levels/packaging/complex numbers

robert_weir@us.ibm.com wrote:
> I don't agree with that logic.  Imagine you have a PDA spreadsheet. 
>  Then you are given a valid ODF document which matches your subset of 
> functionality.  You can read it and process it with no problems.  Any 
> document you create on that implementation, is by default valid ODF and 
> can be read by any ODF-compliant implementation.  Further if someone 
> sends you a spreadsheet which you cannot handle, then you need to handle 
> that as an error condition and degrade gracefully, notify the user, etc. 

Just to make sure I understand your proposal. You suggest that a PDA can 
be called ODF compliant even if it is not able to support all the 
formulas specified in the ODF formula spec? Or do you suggest that we 
design a spec that can't be fully implemented in a resource-limited PDA?

There are pros and cons to these approaches, but before I comment I want 
to make sure I understand what you suggest.

> Presumably an implementor knows their users/customers best and will give 
> them the functions they want, regardless of what levels we define.  The 
> real purpose of the spec is not to tell implementors what features they 
> need to write, but to give them a common way to express the features 
> they do decide to implement.

I'll need to think about this, but I guess that's a reasonable way to 
define the goal of the spec. So, "compliant" wouldn't mean "you must 
include all these functions" but rather, "any of these functions you do 
provide must be written like this".

I think I can be persuaded for that approach. The consequence is that a 
file made in compliant app A might not open in compliant app B. But this 
would only happen if app A legitimately provides a feature that app B 
does not.

      /\/`) 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]