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


Help: OASIS Mailing Lists Help | MarkMail Help

opendocument-users message

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

Subject: Re: [opendocument-users] Concerns about the way of formula standardization

Jörg Wartenberg <OO@WorldWartWeb.com> wrote on 01/25/2006 07:04:21 AM:

> My concerns:
> 1.) Why should this formula format be for spreadsheets only? Isn't it be
> possible to make the syntax universally enough to use it in other kinds
> of applications too?

Speaking for myself, not the TC as a whole, I think the intent is to remedy the existing lack of a spreadsheet formula language in order to allow interoperable exchange of spreadsheets.  I don't think we have the explicit goal of producing a general-purpose formula language for use in all applications.  That general problem has already been addressed before, i.e. EcmaScript, XPath, etc.  In fact, if we didn't have legacy expectations about what spreadsheet formula syntax looks like and how spreadsheets behave, I wonder if we would just use/extend XPath rather than reinvent the wheel?

> Some example applications, where such formulas could be useful too:
> -Calculations in text processor tables
> -Calculations in web applications with data from a database
> -Calculations inside a webpage (data downloaded from a different source
> than the webpage that contains the formula)

You could certainly argue that calculated tables in a text processor are within scope of TC, therefore should be with scope of defining a formula language.  But I'm not sure the other items are in scope of the TC's charter, which is XML-based office application document formats.

> 2.) Why define the formula as 'value of the table:formula attribute'. Is
> a string really the best way to store structured information like a formula?

There is a precedent for storing structured data in a string, even in the best XML formats.  For example, we say href=""http://www.oasis-open.org/"" rather than:


Either way has its advantages.   Personally, I think all attributes which contain internal structure are evil, but some are useful evil.

> 3.) One of the great things on the OpenDocument format is, that it's
> defined independent from the existing data structures or user interface
> of a specific application. Please continue this level of abstraction
> with the formula specification and define only the storage format. Keep
> it independent of the expression that the user will see in the user
> interface of an Excel like application.

I think this is key.  As an interchange format, ODF should allow all sorts of application innovations.  If someone prefers create a visual metaphor for specifying spreadsheet formulas such that the end-user never sees SUM(A1:A20) then that would be great, so long as the application knows how to write out the correct interchange format.  But I do realize that in some spreadsheets the storage format and the display format are almost identical, and any move away from that would require some application changes.  I'm sure we'll hear arguments on both sides of this and eventually come to some consensus.  That's what open standards development is all about.


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