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

Daniel Carrera <daniel.carrera@zmsl.com> wrote on 02/28/2006 04:03:36 PM:

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

Keep in mind that no one has defined "compliance" for ODF, at the TC level or otherwise.  This is an open question.  So this is my opinion only.  I'm proposing a rather minimal conformance criterion, one that acknowledges that we're defining a markup language for documents, but we're not defining a specification for spreadsheet applications.  Not everything that operates on ODF documents is an editor or even needs to be aware of formulas.  For example, a program might just be a standalone convertor of ODF to PDF format.  Is it only ODF-compliant if it implements a particular level of formulas?  The question doesn't even make sense, because this program doesn't even need to know about formulas.  But still it should be able to call itself ODF-compliant.  

I remember talking to a woman back around 1991 who was using 1-2-3 R2.3, the then current DOS release to create her wedding invitations in.  This was the only program she had on her PC which allowed her to do WYSIWYG layout of test.

My point?  There are programs beyond spreadsheets which will read, create and modify ODF spreadsheet files.  And there are uses of spreadsheets beyond formulas.  You never know what clever users and programmers will do next.

So, to me compliance is:  If you write an ODF file, it must be valid according to the specification's normative language, i.e., the RNG and other constraints.

I'm not sure there is such thing as ODF-compliance for an application which merely reads ODF other than accepting all valid ODF documents and degrading gracefully if reference is made of an unimplemented feature.  

You could imagine a compliance test for an ODF-based spreadsheet application, but I think that a different thing than a compliance test for an ODF document.   This is a key distinction.  The name of this TC is "Open Document Format for Office Applications", not "Office Applications using Open Document Format"

I could imagine, for example, a spreadsheet optimized for screen readers for the blind which doesn't bother to waste time with a WYSIWYG layout, forgoing that use of memory and related processing in favor of a small footprint and faster performance.  So long as it saves valid ODF markup, are we going to call it anything other than compliant, just because it doesn't display charts?

Or if in Japan they want "donut" charts rather than "pie" charts?  

There is a whole world of possible spreadsheet-like applications which could use ODF to do some pretty innovative things, but this would mean breaking some assumptions of the desktop spreadsheet editor world.

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

Interoperability will be a key factor in ODF's success.  Specifically, interoperability among a subset of ODF implementations that we would all generally recognize as full conventional desktop spreadsheets applications.  The ODF spec needs to think broader than this, but that shouldn't prevent the vendors from coming to an agreement on interoperabilities in their realm.  This would need to be more than formulas, including things like macros as well.  They can call it a "ODF Desktop Spreadsheet Application Compatible Functionality Profile" or something like that.  Let them define a test suite for self testing or 3rd party testing and certification.   It would be hard, but important, work, but I think it is outside the scope of our charter.  

In summary, I'm suggesting that the world of ODF is larger than our conventional desktop applications, so we need to be careful not to stifle innovation by tieing a definition of spec compliance too tightly to that type of editor.  Of course, interoperability among the desktop spreadsheet applications is important.  We can facilitate it, but not compel it, by writing a good, unambiguous formulas specification.  A larger, separate effort is required on ODF interoperability, including testing, logo certification or whatever.  I think an interoperability specification would logically arise as an end product out of that effort.


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