Weds. call

[Patrick Durusau <patrick@durusau.net>]

Greetings!

Sorry for the long silence!

For the meeting tomorrow I would like to see us discussing (probably not 
resolving) the scope of the OpenFormula work.

As you can see from my rather extensive comments, see:

http://www.oasis-open.org/apps/org/workgroup/office/download.php/30630/Formula_Conformance_20090111.odt

I don't have an ax to grind one way or the other on most spreadsheet 
issues but I do need to know what we are trying to do.

For example, if we want formula expressions to conform to whatever 
requirements we set forth, then we simply say that. We don't offer 
advice on what some theoretical minimal application might or might not 
do. Either it conforms to whatever we have created as conformance 
requirements or it doesn't. A necessary (but probably not sufficient) 
basis for interchange is that an application conform to whatever we say 
it must conform to in OpenFormula. That some applications somewhere may 
do other things may be interesting but not terribly relevant.

Rob has said that we could define a theoretical application in order to 
define conformance, which is true, but I am not sure we have the time 
remaining before ODF 1.2 with OpenFormula needs to move forward.

I suspect the scope issue will consume one or more meetings. But, just 
so everyone is aware of other issues of concern, I am deeply concerned 
that the OpenFormula work has defined its own datatypes. Particularly 
since that means that a "conforming" "????" can return a complex number, 
a complex number as text or some other data type as the result of a 
complex function. That may work to cast our net as far as possible but 
that doesn't sound very "standard" like to me. A standard pronounces the 
"correct" function and its outcome, including datatype and either you 
got that or you don't.

I haven't gotten to read all the functions in detail and to compare them 
to ISO 29500. Some of you will recall that David Wheeler has 
experimentally determined what Office 2007 does for YEARFRAC, which is 
different from what ISO 29500 defines. And several of you will recall my 
questions about our definitions of that same function. It would be very 
sad if we have gratuitous differences from ISO 29500 on any part of the 
formula work. Legitimate differences are ok, let's us really try to not 
have any simply to be different or to be "right."

(From my unfortunate venture across as many as 1/2 dozen accounting 
organizations in search of the "correct" answer for YEARFRAC, the notion 
of a defined "correct" answer hasn't occurred to the accounting 
community. Apologies to any accountants on the list but the near 
universal answer was: "Get the same result as software X." That doesn't 
strike me as a useful answer. Or at least not one that I can write down 
in a standard.)

Looking forward to the call tomorrow although I am going to be listening 
and trying to formulate questions to tease out what the formula 
subcommittee already knows!

Hope everyone is having a great evening!

Patrick

-- 
Patrick Durusau
patrick@durusau.net
Chair, V1 - US TAG to JTC 1/SC 34
Convener, JTC 1/SC 34/WG 3 (Topic Maps)
Editor, OpenDocument Format TC (OASIS), Project Editor ISO/IEC 26300
Co-Editor, ISO/IEC 13250-1, 13250-5 (Topic Maps)