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

[Jody Goldberg <jody gnome org>]

On Tue, Mar 11, 2003 at 09:24:54AM -0500, Russell McOrmond wrote:
>   You need to remember that OpenOffice.org is a derivative of StarOffice
> which has/had its own (binary) file format.  The OpenOffice.org XML format
> may have been created with some knowledge of the internals of StarOffice,
> but it is not its 'native format' any more than it will be for GNUmeric or
> AbiWord.

It is native in that it was created based primarily based on the
feature set of OpenOffice.  Many of the limitations are inherited
by the requirement to support xls style operations and as such
aren't significant.  Others are just related to the fact that OO has
a specific feature set that is different from what Gnumeric and
GNOME Office provide.

IMO there is simply no way for the format to be able to express a
superset of all possible spreadsheet functionality while remaining
implementable.  As an example,  I'm experimenting with a form of
conditional formats that is different from MS Excel.  Rather than
only supporting some fixed number of conditions with attached static
styles Gnumeric will also have the notion of a calculated style.  A
user will be able to say
    'background colour == lookup_color(current_value, table)'

Neither OO nor Excel have such a notion.

Other assumptions relate to expression syntax, and semantics.
    - Sheet names may not contain '.' or ' '
    - There is no notion of sheet local named expressions
    - The available error types are OO specific
    - The semantics of ranges for scalar operators is
      poorly defined and slightly different from MS Excel for
      non-array valuation expressions.

and that list does not even begin to touch on the function
specifications.  It is my considered opinion that file formats, at
least for spreadsheets, are simply too high in markup relative to 
content for them to be standarized.  It is certainly useful to
support some common format as an exchange medium, but it tempting to
leave xls as that form for now given its pervasiveness.

> What do you do with content
> encapsulated within tags that you don't understand?

That is an excellent question.  While working on specifications for
the packaging conventions, and content for Gnumeric's next
generation file format I'm trying to generate support code in libgsf
to handle just that sort of thing.  So that it will be feasible to
store the unknown content for later.  However, even that is pretty
weak, with only a very small subset of the content potentially
stored.  Its simply too difficult (performance and memory) to have a
generalised storage.  I'm advocating supporting generalised content
for only a subset of elements for which there are data structures to
maintain the data.

eg
    Cell/Sheet/Workbook

essentially limiting support to things that are easy to name, and
have clear lifecyles for the user.  Tagging something like a style
gets dicey quickly because a user doesn't know the life cycle of a
style.