Re: Open Office file formats (Oasis-open) and gnumeric



On Sun, Mar 16, 2003 at 06:37:37PM -0500, Russell McOrmond wrote:

  The best analogy at this time is to Web browsers.  There is a lot of
innovation possible (and happening) with web browsers, but it is best when
this is not at the HTML, HTTP (or worse, TCP/IP) layers.

  Users who are doing ColdFusion on their websites know that they are
doing ColdFusion, know that they aren't doing HTML, and should understand
that not everyone will be able to see their documents.

There are two problems with that analogy.

1) The ratio of authors to viewers is very different with Office
applications and web pages.

2) There is no layer equivalent to ColdFusion for spreadsheets.

If all FLOSS suites don't interoperate "as the default"  
for the features of spreadsheets that most people use, then the share of
the market that Microsoft currently enjoys may never change significantly.

MS Excel will continue to dominate until free alternatives cover
enough of its _functionality_ to offer viable replacement.
Supporting its file format is irritating, but somewhat secondary.
The feature set drives the interoperability not the parsing.

  Is it better to dumb-down the feature set within interchange file
formats to achieve this compatibility, or continue to 'enhance' the tools
in ways that keep them incompatible?  Is this something worth getting
together with other FLOSS suites to work on?  Will folks from GNOME
Office, KOffice and OpenOffice.org be willing to come together on this to
try to push compatibility as a way to grab market share from Microsoft?

Its not a question of dumbing down.

Let me turn the issue around.  Can the OASIS format represent an xls
file with no loss of information ?  It doesn't look like it to me
(sheet names limitations, no sheet local names, differing autofilter
semantics).  If that is correct then we're already somewhat behind
the eightball.  There is no choice between MS Office compatibility
and OpenCalc, MS wins.  The goal is to supplant an entrenched
application with overwhelming market share.  We need to interoperate
with it.

Or from yet another perspective.  What happens when OpenCalc has
different evaluation semantics than MS Excel.  A user can create a
file using an OASIS format that uses a different date convention
that neither MS Excel, nor Gnumeric supports.  Every date in that
valid file is going to be mis-displayed outside of OpenCalc.  That
flag is in there because older versions of StarOffice used the
convention.  Do the rest of us need to support it ?

How about calculation differences ?  OpenOffice's support for
iterative expressions is not as strong as MS Excel.  Loading an xls
into OpenCalc will generate incorrect numbers at times.  Gnumeric is
strong enough to handle it.  Do we just mandate that because
OpenCalc defined the file format the other stronger implementations
are 'enhancements' ?  Is the application penalized because it has
done more work ?

What about size differences.  Ignoring limitations on the number of
sheets
    MS Excel = 256x64k or 256x16k
    OO       = 256x32k
    Gnumeric = 256x64k (customizable)
    kspread  = 32kx32k

We can disregard performance in this argument (eg do not attempt to
load 256x16k cells into some of the apps).  However, the question of
what to do with extra data is important.  This also ties into how
the application handles references.  In MS Excel 1 cell to the right
of col IV (256) is Col A (1).  There are files that make use of that
property, which is why Gnumeric is shipping with that as a default
size right now.  The file format is just the final dunping ground
for piles of implicit detail.

The core issue here seems to be in our perspective of what a
spreadsheet is.  You seem to see them as a means of viewing content.
Whereas, unsurprisingly given my position, I tend to view them as a
development platform.  Having to implement all of those implicit
details has driven home jsut home much of them there are.

We'll probably meet in the middle one day, but I suspect not just
yet.

Best Wishes
    Jody



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]