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
- From: robert_weir@us.ibm.com
- To: Jörg Wartenberg <OO@WorldWartWeb.com>
- Date: Thu, 26 Jan 2006 17:07:03 -0500
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:
<url>
<protocol>http</protocol>
<host>www.oasis-open.org</host>
<port>80</port>
<path>/<path>
</url>
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.
-Rob
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]