Re: [office-formula] Goals/levels/packaging/complex numbers

[robert_weir@us.ibm.com]

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.


-Rob