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: Specifying formula syntax


Michael Brauer said:

> Regarding formula and expression syntax: The fact that the OpenDocument
> specification does not specify an exact syntax and semantic for them,
> but only a method for including a syntax and semantic defined outside
> the OpenDocument specification, has been discussed already several
> times...

> That is, we have the topic on our agenda, and we have a proposal for a
> standard, but we consider the topic to be out of the scope for this
> release of the OpenDocument specification. 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. So I don't think that this situation
> can be compared with XSLT, but more with HTML and CSS or HTML and
> scripting languages, where HTML also only specifies how styling and
> scripting information can be included, but does not specify the syntax
> and semantic itself.

Ah, but this analogy doesn't apply.
It is quite useful to have an HTML-only browser, which simply
ignores the CSS and scripting language text.  Without CSS a web
page is "less pretty", and without scripting languages you lose some
functionality in a few pages (a few pages won't even work).
But for 99% of all HTML pages, an HTML-only browser is fine.
I've often used trivial HTML browsers (e.g., old lynx versions)
as a way to test portability, and they're extremely useful.
Clearly, an HTML browser without CSS and scripting is useful.

On the contrary, a spreadsheet program that can accept Calc
XML files but cannot calculate their values is essentially useless.
Formulas are not "external optional data", they ARE they data.
Formulas are the WHOLE POINT of having a spreadsheet.
Spreadsheet users expect to be able to change a value
and have the other values recalculate; that's the whole
point of a spreadsheet program.  So a calc format that
can't share formulas is a calc format that can't exchange
data, and that's the whole charter of the group.

The question should never be "is this XML?".
The question should be, "does this spec permit me to
exchange documents?"  Users don't care that some of the
values are actually expressed in a mini-language... what they
want is document exchange.

> 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.

If I took that argument to heart,
the entire OpenDocument spec could be replaced by the
XML Namespace spec.  After all, the Namespace spec lets you
use a namespace prefix to unambiguously specify the
syntax and semantics of the data, which are then defined
somewhere else...!

We all agree that wouldn't help.... someone has to go down
and define the syntax and semantics of the data in detail,
so that the data can actually be exchanged.
Which is the genius of the OpenDocument specification... it
generally DOES work hard to define the syntax & semantics
to permit data interchange.
In general, the OpenDocument specification goes into quite
a bit of detail so that user data can be correctly interpreted
(for Ruby, etc.). It seems grossly inconsistent for it to not
define a useful syntax for formula data exchange, while
defining in detail how to exchange Ruby.  Many users never
see Ruby, but essentially all spreadsheet users see formulas.

If your argument is, "formula syntax should be defined in a
separate document so it's easier to maintain separately",
then from one viewpoint that makes sense.
But then the group needs to hurry & create that separate document
so it can be included by by reference.  For example, when HTML was
defined, the URI/URL syntax was defined at the same time,
and included by reference.  URI/URLs aren't in
SGML or XML format, but normal HTML use doesn't
make sense without them.  And you've already been provided
a draft of such a document; I'd be happy to help you fix it up
if that's the problem.

I respectfully request that the committee reconsider,
and that the spec somehow (directly or by reference) include at
least one standard way to exchange formulas.
The committee agreed that formula syntax was vital for information exchange.
The charter says that this specification is
"a standard for office document processing and interchange", and that it
must include "high-level information suitable for editing the document".
If the standard won't standardize the very data it's
supposed to exchange, it's greatly weakened.
And it appears that I'm not the only one with that
viewpoint; James Clark is a highly respected, and I
never mentioned this to him (he made this determination
independently).  Having namespaces to allow future
flexibility is a great idea, but you need a place to start
for interoperability.

An obvious way is to define this in a separate document,
and have it included-by-reference as a normative reference.
I think that might resolve all parties' issues.

Respectfully,

--- David A. Wheeler


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