Re: [office] Conformance Clause proposal, Version 8

[Andreas J Guelzow <aguelzow@math.concordia.ab.ca>]

On Sat, 2009-02-07 at 10:16 -0500, David A. Wheeler wrote:
> Andreas J Guelzow wrote:
> > I really see no chance of avoiding incompatibilities between spreadsheet
> > applications, considering the current draft of OpenFormula. Some (many?)
> > functions contain "implementation defined" results for at least some
> > possible arguments. Unless there is some verification mechanism to
> > ensure that those argument values cannot occur, the standard cannot
> > expect interoperability for conformant spreadsheet applications.
> 
> I don't think that's true. Nearly all standards have SOME 
> implementation-defined behaviors.  Documenting them lets users know what 
> to avoid.
> 
> Nearly all _REAL_ spreadsheets don't depend on the 
> implementation-defined behavior in the first place.  I fully expect that 
> typical spreadsheets _will_ interoperate just fine.  If there's a case 
> where that's not true, _AND_ can be fixed, please help us identify them 
> so we can try to fix it.
> 
> > For example VLOOKUP a function in the "small" and so required by
> > virtually any implementation may expect the DataSource (one of its
> > arguments) to be sorted. But the sort order required may depend on
> > whether the application implements a separate "logical" type. If
> > DataSource is not sorted, the result is undetermined and
> > implementation-dependent. Since the same DataSource may be sorted for
> > one application and not another, I am not sure how one could expect
> > interoperability.  
> 
> But this only matters if you mix logical and number values in the same 
> column, and then sort on that.  That is EXCEEDINGLY improbable, and 
> wouldn't even make sense to most users.   Indeed, this possibility 
> wouldn't even occur to most users, because many programs don't even 
> permit mixing of data types like that. Typically a VLOOKUP will be on a 
> column with one data type - typically Text (string) or Number - and as 
> long as you use the same type consistently in a field column, this works 
> just fine.
> 
> Which justifies my point.  Yes, there are some implementation-defined 
> behaviors, in this (and nearly all other) specifications.  That lets 
> users know what to avoid, and helps them create spreadsheet documents 
> that DO interoperate.
> 

Is this column sorted:

FALSE
MAYBE
TRUE
TRUE
TRUE
UNLIKELY

It looks sorted to me, so I paste it into OO3.0 and Gnumeric 1.9.4 into
cells C1 to C6

I add the formula
=vlookup("MAYBE",C1:C6,1,1)

now the results are _not the same anymore. Gnumeric yields what I would
have expected: "MAYBE" while OO3.0 yieds "1" ??

Of course this has to do with the fact that the internal representation
of the pasted column differs between the two. (You can see this when you
save it in OO3 as an ods file and open it in Gnumeric (ignoring the
warning messages gnumeric brings up regarding the file format). You
can't save it as a gnumeric file and open it in OO3.0 since OO can't
handle that.)

But you really think that your typical user can understand these
restrictions on the range or just thinks that the implementation defined
answer makes really sense? See for example the second problem listed
in  
http://bugzilla.gnome.org/show_bug.cgi?id=567389

Andreas 



-- 
Andreas J. Guelzow
Concordia University College of Alberta