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


Help: OASIS Mailing Lists Help | MarkMail Help

office message

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

Subject: Re: [office] Part 2?

Patrick Durusau <patrick@durusau.net> wrote on 02/12/2009 04:27:25 PM:

> Already proofing on part 1 and ran into an issue that may involve part 
> In the introduction (1.1 in the current draft) we say:
> > Part 2 defines a formula language for OpenDocument documents.
> >
> But that's not right is it?
> Shouldn't it read:
> "Part 2 defines *the* formula language for OpenDocument documents."
> And then later under conformance, we will need to account for allowable 
> values for text:formula and table: formula being defined by Part 2. Yes?

This came up during the conformance discussions last week.  My impression 
is that this question needed more discussion, and the language may be 
revised.  I don't think it should hold up the draft.

So what is the relationship of Part 2 OpenFormula to Part 1's conformance 
clause?  We have a few potential ways of relating them:

1) OpenFormula is required to be used exclusively in all documents of both 
conformance classes, for the values of table:formula.

2) OpenFormula is recommended to be used in all documents of both 
conformance classes, for table:formula, but other extension namespaces may 
be used instead.  In that case, spreadsheets formulas will not be 
interperable across implementations.

3) OpenFormula is required to be used in default conformance class 
documents, but is only recommended for "extended" class documents.  Other 
namespaces may be used in "extended" class documents.  In this case, 
"extended" class spreadsheets will not be interoperable.

I think we need #1 here.  David and his SC did a great job over the past 
few years of looking at the range of spreadsheet behaviors, even 
thanklessly taking into account the needs of vendors who were not 
participating in the ODF TC at the time.  Not agreeing on a common formula 
language for a spreadsheet would be akin to not agreeing on a common text 
styling vocabulary for a word processor format. We should use OpenFormula 
as it was intended, as the value of table:formula.



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