Re: [office-comment] Public Comment

[Michael Brauer <Michael.Brauer@Sun.COM>]

James,

thank you very much for your comments.

Regarding formatting numbers as natural text: OpenDocument differs
between number values and formulas on the hand, and displaying number
values on the other hand. The later one is controlled by the so called
data styles that are described in section 14.7. An RFE for formatting
numbers as natural text would mean that the definitions of these data
styles have to be extended, but that the definition of formulas would
remain the same.

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. See for instance

http://lists.oasis-open.org/archives/office-comment/200410/msg00025.html

The TC's current position regarding formula syntax can be found here:

http://lists.oasis-open.org/archives/office/200501/msg00004.html

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.

Best regards

Michael Brauer

OASIS OpenDocument TC chair




comment-form@oasis-open.org wrote:
> 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

-- 
Michael Brauer                                Phone:  +49 40 23646 500
Technical Architect Software Engineering      Fax:    +49 40 23646 550
StarOffice Development
Sun Microsystems GmbH
Sachsenfeld 4
D-20097 Hamburg, Germany                e-mail: michael.brauer@sun.com