[odf-discuss] Response from a GNOME Foundation board director

[Jody Goldberg]

On Fri, Nov 02, 2007 at 03:42:23AM -0700, Daniel Carrera wrote:
> --- jody at gnome.org wrote:
> > Our (Gnumeric developers) perspective is that we are a neutral third
> > party, and both specs have made our lives unpleasant.  Each has it's
> > own irritations and benefits.  Neither is going to be 'perfected'
> > into being the one true office format as far as I can tell.
> 
> Well, no such format can exist. And if you try to make a format
> that is all things for all people you end up with TIFF.
I am not familiar with the intricacies of TIFF, but agree with the
rest of your characterization.  It's one of the reasons I fear the
prospect of 'extending ODF to support MS Office' the result would
likely be of little use to OO.o.

> With that said, have you considered extending ODF with features
> that Gnumeric has but OOo lacks? ODF allows extension, and OOo can
> hardly complain since they extend it too.

Somewhat.  Some of our complaints are structural.
    - no shared formulas, and very limited shared value support [it
      only works if an entire row is constant.  This is a massive
      performance hit in space and time.

    - implicit positioning and data allocation.  We'd rather take
      the space penalty and specify the locations of each cell, or
      the data associated with a series dimension.

    - Limited by design in areas where OO.o is weak.  For example
      data validation or conditional formating.  The design limits
      what is possible.  To make it stronger we'd need to break
      older versions significantly.
> 
> > These formats are the file formats of their native
> > applications.
> 
> Well... ODF doesn't have crap like LineSpacingLikeStarOffice="1"
yes, and no.  What do you think will happen when the new numbering
spec is adopted in 1.2 ?  We'll end up with some of those sorts of
funkiness popping up.

> Yes, ODF is based on OOo's view of the world (e.g. frame based vs
> page based) but IMO it is far more generic than OOXML. ODF seems
> to borrow more from HTML and other existing standards than from
> OOo itself.

At the high level that's true.  The Table layout in calc is clearly
being driven by a different set of design goals from a spreadsheet.  
Which is something of a mixed blessing, and I'll give it the benefit
of the doubt as a good try.   However, as you descend further in,
getting closer to the nuts and bolts of various features things
become very OO.o specific.

    - autofilters can not represent MS style condition relations
    - Differences in styles
 
> 
> Would you rather the Formula spec simply copy whatever Excel does
> even if it's wrong or inconsistent ?
Wrong ? no.  Accuracy trumps interoperability.
Inconsistent ? yes.  Interoperability wins.

> Should we force applications to say that 1900 is a leap year
> although it isn't because many years ago a Microsoft programmer
> got it wrong?
Actually it was a lotus developer, I think.  Dunno how far back the
mistake goes.

> A moment ago you were complaining about ODF and OOXML being
> application specific.
Actually I was not complaining.  Given the state of play in 'office'
applications.  I don't think a universal format is feasible today.
That said, it would have been nice to just accept the defacto
standard in such a central piece of spreadsheet interop.

> >  f="xl:SUM("1")"
> > It would be valid ODF 1.1, and possibly even 1.2 depending on how
> > the lawyers parse things.  Early versions of OO.o would not be able
> > to read it, and the newer variants that helpfully ignore the
> > internal name-space entirely would calculate different results.
> 
> Let OOo do it wrong then. Have Gnumeric do it right, and MS Office
> users will migrate to Gnumeric instead of OOo.

That's actually, with a small adjustment, that's a pretty good
summary of my general approach to all of this.  One of our main
goals is to make it as easy as possible for the largest set of
spreadsheet users (Excel) to migrate to Gnumeric using a two prong
approach
    1) Be better than XL, and enticing
    2) Make the transition as painless as possible.  Even if that
    means facilitating overlap.