Public Comment

[comment-form@oasis-open.org]

Comment from: jjc@auth-only.jclark.com

So I'm trying to spec an RFE for OOo 2.0 for Calc
for formatting numbers as natural language text
(e.g. 42 as forty-two).  Two Thai versions of
OOo have independently implemented this
extending the OOo 1.0 format in incompatible ways,
thus creating interop problems.  I think to
myself: OOo 2.0 is using this cool new
OpenDocument format, so the key problem is
going to be extending the OpenDocument format
to specify this formatting extension. So I
download the spec, and search for the section
where the Calc formula syntax is specified, and
I search, and I search...and I find things like

	<attribute name="table:expression">
		<ref name="string"/>
	</attribute>

and

<define name="formula">
	<!-- A formula should start with a namespace prefix, -->
	<!-- but has no restrictions-->
	<data type="string"/>
</define>

and

<table:named-expression table:name="sample3" 
		table:expression="sum([.A1:.B3])"/>

and

"The table:condition attribute specifies the condition that must evaluate to “true” for all cells the validation rule is applied to. The value of this attribute should be a namespace prefix, followed by an Boolean expression.
A typical syntax of the expression may be similar to the XPath syntax."

I really hope I'm missing something, because,
frankly, I'm speechless.  You cannot be serious.
You have virtually zero interoperability
for spreadsheet documents.

To put this spec out as is would be a bit
like putting out the XSLT spec without doing
the XPath spec. How useful would that be?

It is essential that in all contexts that allow
expressions the spec precisely define the syntax
and semantics of the allowed expressions.

Using a namespace prefix is a nice idea, but
it needs to be required (and enforced by the
schema), and then you need to define a namespace
that contains at least the basic functionality
needed by a spreadsheet, and preferably
everything supported by OOo 2.0, and precisely
define the syntax and semantics of expressions
associated with that namespace.

OpenDocument has the potential to be 
extraodinarily valuable and important
standard.  I urge you not to throw away
a huge part of that potential by leaving
such a gaping hole in your specification. 

James Clark
http://www.jclark.com/contact.html