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


Help: OASIS Mailing Lists Help | MarkMail Help

office-comment message

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

Subject: Re: Very Weak String Support in ODF

David A. Wheeler wrote:
> I'm not fundamentally opposed to adding a few string functions (primarily to the "Large" group), but generally we've only been including functions which are ALREADY implemented in at least ONE spreadsheet application (Excel, Gnumeric, Corel Word Perfect Quattro Pro, KSpread, Lotus 1-2-3, etc.).  There's no end to the number of functions that COULD exist, and the lack of presence in ANY implementation is a sign that perhaps this isn't as widespread a need as you'd think. Spreadsheets tend to not be used for a lot of text processing (though which is the cause and which is the effect could be argued, I guess).

I like to correct this.

Spreadsheets are *THE MOST* used input medium that researches use in 
biomedical and life-sciences. This is both true of my country and of ALL 
western countries  I am aware of. Actually, spreadsheet use will likely 
increase in the future, as more data gets digital. My position permits 
me to fairly accurately predict this.

Of course, custom solutions could replace spreadsheets, BUT then only 
because spreadsheets did NOT correct the primary design flaws.

So, the current stance prohibits the effective use of spreadsheets in a 
big segment of users. The life sciences are NOT the only one affected, 
actually, a much broader segment of researchers are struck with these 
shortcomings, and even commercial businesses. I am working in a 
governmental office and some 30-40% of ALL spreadsheets, done by ALL 
employees, contain significant portions of text. (I mean with text that 
is analysable, NOT just labels or descriptive text!)

> Also, there's always a risk that "committee invention" will have implementation or usage problems.  Standards are generally better when they stick with what's already in use, and make sure that they're extensible for future experimentation.  Yes, such functions certainly exist in other languages (so the risk is lower), but there's still a risk that a definition would have a hidden problem unless at least ONE supplier has implemented it with the other functions that ARE defined.  #3 in particular presupposes support for arrays of variable size, which certainly NOT all implementations support (nor do they need to for many use cases).  #1 and #2 are easy enough, though I'd like to know what to name #1.

STANDARDS should NOT depend on the implementation. That would be a poor 
standard. It usually should be the other way round. ;-)

#1: FINDEX() and SEARCHEX() as already proposed in a feature request on 
the OOo site

It is interesting that, although I extensively use *text* spreadsheets, 
I don't remember using the built-in FIND() and SEARCH() for years now. 
That says something about the usability of these functions. Actually, 
even my colleagues don't use them.

One thing in common that every study on human errors has brought to 
light is that errors increase as formulas get more complex. The 
workaround for the FIND/SEARCH()-problem makes the formula definitely 
more complex, what do you think?
  1.)     = OR( FIND("a"; ...) ; FIND("b"; ...) )
  2.)     = OR( IF( ISERR( FIND("a"; A1) );  0 ; FIND("a"; A1) ) ; IF( 
ISERR( FIND("b"; A1)) ;  0 ; FIND("b"; A1) ) )

Please feel free to correct the above formula IF you find the error. I 
was NOT able to make OOo Calc compute it. After more that 15  minutes I 
gave up.

3# ARRAY functions are needed in the broader context of data analysis, 
NOT purely to get the array, but to do various vector operations.

I am looking to the future with optimism.


Leonard Mada

> It's certainly a reasonable idea.  Is there anyone else who believes we should add these functions at this time?  If so, can you point to a reasonable definition for them?  If there's significant support, let's do it... but if not, let's wait.
> Actively-used standards, like OpenDocument, are typically revised occasionally.  So there's reason to believe that there will be a future opportunity, if they aren't included at this time.  In particular, OpenFormula includes a naming scheme that will allow implementations to add new functions that don't interfere with others, and then the ones that become popular can be added to the standard space.
> --- David A. Wheeler
> Thanks for your comment!

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