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
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
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:
> can implement formulars in their own way without being an open
...OpenDocument doesn't specify the formulars used in spreadsheets so
every spreadsheet vendor
This way a vendor can create lock-in to their
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
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
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
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