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] Conformance Clause proposal, Version 8


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.

--- David A. Wheeler



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