OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

office-comment message

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

Subject: Re: [office-comment] OpenFormula (OpenOFormula?)- I'm working ona draft.

Hi David,

Thanks for the concerned comments and all the considerable effort you have put into solving this problem.  You're challenging us all to go where none have dared tread before.  So go ahead and lead the way.  You have the TC's attention.  We are listening.  As you grind out the grit of your proposal, please keep in mind that we have to fit proposed solutions into the politic of work that has already been done.  A politic that represents years of work that is just now on it's way to ratification at OASIS, and beyond to ISO.  Keep in mind also that the ISO certification comes at the request of the European Union. Time is of the essence.  Ratification perhaps trumps perfection.  At least for the moment.

We are very much aware that whatever we leave outside the specification remains open (or not) and exposed to ambiguities and custom implementations, all of which have proved to be so problematic in the past.   While we need to keep pushing, there is also the need to complete phases of the work to the specification, so that we can move it to the center of the world's stage as soon as possible.  Rome wasn't built in one day.  And it wasn't dropped from the heavens as a fait accompli either.

Your kindness in the way you're approaching this issue is much appreciated, and i personally like your proposal for a separate standalone "OpenFormula" specification.  It may be a good way to break through the logistics of the current specification situation, while allowing room for the continued push to develop a truly universal file format that covers the ever evolving needs of a rapidly expanding productivity environment.  I'm even wondering if this isn't something that should be tossed back to the OOo Community as a project?  One of the great attributes of the OASIS OpenDocument TC is that we have armies of engineers and beta testers from OOo, StarOffice, and KOffice waiting to rip into the next insolvable problem, and do what has never been done before :)

Thanks for your concern and contribution David.  And thanks to James Clark and Claus Agerskov for voicing their concerns.  We hear you.  We appreciate the help.


OpenOffice.org volunteer serving on the OASIS/ISO OpenDocument TC

David A. Wheeler wrote:
Comment from: ca@chbs.dk

...OpenDocument doesn't specify the formulars used in spreadsheets so every spreadsheet vendor
> can implement formulars in their own way without being an open standard.
This way a vendor can create lock-in to their spreadsheets.

I think this is so important that I'm taking my January 4, 2005
proposal and reformatting it into a separate standalone specification
for formulas, so I can send it in as a proposal to the committee.
The committee did agree that they'd at least post some materials
on their website.  I would really like them to do more; I
hope they'll take my document, change it as they like,
and include it by reference as a normative requirement.

I'm calling my proposal "OpenFormula".  I'm starting with the spreadsheet
tables, but I see no reason to have 12 different formula processors
that are "almost alike" -- that will just confuse the user --
so I'm going to see if I can unify the whole thing.

This previous comment scares me: "There are from our point of
view also no interoperability issues, because the namespace prefix
mechanism we have specified unambiguously specifies what syntax and
semantics are used for a formula".  Here's how I read that:
"Every implementation must reverse engineer
all other implementations' namespaces (they're not in the spec,
so everyone's free to invent their own private incompatible
namespaces).  Then, every implementation must
implement all the syntax and semantics of all
other implementations' namespaces for formulas, if they
wish to achive interoperability.  And oh, by the way, your
implementation might not implement the namespace for the
document you're trying to load, so you may lose all the formulas."
I'm sure that's not what was meant, but that's how it
reads to me.  I hope that helps
explain why I think that the current formula information
in the OpenOffice specification is grossly inadequate.

My doc may get renamed to "OpenOFormula" (Open OpenDocument Formula)
or something else so that there are no name collisions worldwide.

Looking around at the OpenDocument specification, formulas
just haven't been handled well throughout -- and this is fixable
quickly if we hurry. There are completely independent
draw:formula and anim:formula specs which ARE specified
to more depth than the spreadsheet formulas.
The "Table Cell Content Validations" are also better-defined
than the actual formulas.
So you have a better shot at exchanging drawing formulas,
or exchanging validation rules for spreadsheet cells,
than for exchanging the actual equations for spreadsheets. Huh?

And there's also text:formula, which is sort of like
the table formulas except there's no requirement that
they be like each other.

Table:operator and table:condition use "!=" for not-equal,
but OpenOffice internally uses "<>" for not-equal.
No, that inconsistency is
not documented in the current specification, because the
entire formula syntax isn't really well-defined.

In short, the lack of a unified formula definition is a real
problem in the current spec, and it's too bad, because it's
not hard to at least make a first cut at fixing it so that
the syntax and basic operations (+, &, etc.) are defined.

In the longer term, it'll be very important to nail down
a long list of functions and the EXACT semantics of
everything (if you see a string when you were looking for
a number, what do you do?).  But let's at least get the
syntax down, and a short list of functions like SUM().
Many spreadsheets only use a few functions and simple
equations, and don't do things that would hit the edge cases.

Oh, a note about formula namespaces; please let me know
if my understanding here is incorrect.
Section 8.1.3 of Open Document Committee Draft 2, 21 Dec 2004,
says "Every formula should begin with a namespace prefix specifying the syntax and semantics used within the formula. Typically, the formula itself begins with an equal (=) sign and can include the following components..."
And 6.5.3 gives this example:
 text:formula='ooo-w:[address book file.address.FIRSTNAME] == "Julie"'
>From this, I presume that if the first character of a formula
is a letter, it must be a namespace defining
some specialized formula processing system (keep reading til the
colon to find the namespace's name; stuff after the colon is the formula).
If the first character is an "=" sign, then everything after that
is the formula, and the "default"
formula processing system is used.   I think there should be
a single unified formula processing system (subject to the
limits of security issues), so that "+" doesn't change its
meaning unless you use a nonstandard namespace.
I also think there should be a standard name for the namespace
(I suggest the standard prefix "formula:"), so that if you
want you can state things more clearly.

--- David A. Wheeler

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