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


Help: OASIS Mailing Lists Help | MarkMail Help

office-formula message

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

Subject: RE: [office-formula] Calculation Settings

I'm trying to improve interoperability by bring more clarity to this issue.  Indicating that applications shall implement the listed calculation settings is not specific enough, especially in this important area that effects the results of formula calculation.  The starting point for an application would be to calculate new spreadsheets that correspond to a combination of these settings and write values for the calculation setting that correspond to the application behavior.  Next would be to read these values when loading a file and load files containing combinations of settings that are supported.

What is unclear is whether there is an expectation for conforming applications to load and calculate spreadsheets with all possible combinations of settings.

- Table:null-year represents a year.  Are conforming applications required to support any possible value for this setting?

- Table:null-date represents a date.  Are conforming applications required to support any possible value for this setting?

- Table:automatic-find-labels is unreliable and the spec will recommend deprecating this behavior.  Should conforming applications be required to read and implement this deprecated behavior?

To answer these questions and improve interoperability, I'm suggesting that we specify values for these settings that are most likely to be interoperable and either specify them as recommended or as has been done in other parts of the specification, tie them to "portable documents".

I believe that settings that are most portable and produce the best interoperability to be:

        table:case-sensitive = FALSE
        table:precision-as-shown = FALSE
        table:search-criteria-must-apply-to-whole-cell = FALSE
        table:automatic-find-labels = FALSE
        table:use-regular-expressions = FALSE
        table:use-wildcards = FALSE
        table:null-year = 1930
        table:null-date ="1899-12-30"


-----Original Message-----
From: David A. Wheeler [mailto:dwheeler@dwheeler.com]
Sent: Friday, May 15, 2009 10:02 AM
To: Eric Patterson; office-formula@lists.oasis-open.org
Subject: Re: [office-formula] Calculation Settings

Eric Patterson wrote:
> I've been reviewing Calculation Settings and finding that conformance is a bit ambiguous.
> Looking at sections 2.1.1 and 3.3, they indicate that conforming applications shall implement the calculation settings, and that applications may use non-default values for new documents.
> What is unclear is whether support of specific values are required for conformance.
 > For example, table:null-date lists some commonly used values in a
note, but list no values as required for conformance.
 >  Are conforming applications any that read and write a single value
that conforms to the definition of table:null-date?
 > Is application conformance reading all of the settings and only
loading files with the combinations of settings that
 > are supported by the application?

Section 2.1.1 says that applications "shall" implement all the listed
calculation settings to conform to the "small" group.  I'm not sure how
that's ambiguous - can you help me understand why it's ambiguous?  I
interpret "implement" as "implement it for all the legal values of that
type", i.e., an application needs to be able to read all those values
and implement them.

After all, the whole point of standards is interoperability.  If
application A using a setting, but application B can't understand the
setting, then it can't (in effect) process the file at all.  In the
worse case, imagine that application A only permitted one setting (say,
case-sensitive=true) and another only permitted a different setting
(say, case-sensitive=false).  Then, they effectively couldn't share
spreadsheets!!  Most of the values are just true/false anyway, with the
exceptions that table:null-year is an integer representing a year, and
table:null-date is a date.

Anyone disagree with that interpretation?  Anyone believe that the spec
should say something else?  We _could_ require that only a subset of
these settings be supported, especially for "small", but in that case,
we need to specify that subset so that there's there's an interoperable
subset.  I can imagine a smaller subset for "small", expanded by "medium".

--- David A. Wheeler

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