Subject: Re: [office-formula] Goals/levels/packaging/complex numbers
email@example.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. 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?