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: [office-comment] Unit system tracking

Hi all,

1. Typing
2. Marketing
3. TOP 5 Major Design Flaws
4. Multidimensional Spreadsheets

robert_weir@us.ibm.com wrote:
> ...
> At some point I'd like to do some experimentation with an entirely new 
> spreadsheet formula language, designed from the ground up to be more 
> powerful, with features like metrical units (1 meter plus 10 
> centimeters = 1.1 meters),  formal type checking, more vectorization 
> operations, etc.  I'd do this in its own namespace, so as not to cause 
> confusion with the official ODF formula language.  But if enough 
> vendors were interested, this could be added to some future version of 
> ODF as an alternative formula language.

Well, in the last 2-3 years there was extensive interest in extending 
typing to spreadsheets. See e.g. this article:

This is true research done on spreadsheets and not just an opinion. 
Therefore I highly recommend it for reading.

Strong typing is an issue that makes it in my personal TOP 5 of major 
design flaws of existing spreadsheet programmes.  I filed this issue on 
the OOo bugzilla, too (see 
http://www.openoffice.org/issues/show_bug.cgi?id=79924) and included 
some of the useful comments posted previously on this thread.

Please note that, as typing allows catching a lot of serious errors (I 
anticipate one third of significant errors), this is really something 
that helps businesses.

A basic principle of marketing is to *follow the money*.

On the same idea, a feature that prevents losses induced by spreadsheet 
errors is really something that most big businesses will be eagerly to 
implement. So I have to disagree strongly against  limited market 
potential for such a feature. Au contraire,  most big businesses will 
want to adopt it.

There are actually *two groups* that should be specifically and 
aggressively targeted:

  i.) the *research community*:
      - NO financial power, BUT innovating potential
      - implementing units will surely foster adopting this through the 

  ii.) the *financial community*, especially bigger businesses:
       - potential for real *big revenues*
       - strong currency typing is needed

I even anticipate, that if such a product becomes available (from 2 
independent vendors), a lot of countries would adopt legislation that 
would request financial institutions to use only software that has 
error-preventing mechanisms. And this is not the type of "ODF vs OOXML" 
discussion (which in my opinion has no real value; businesses will 
always invest huge sums in software/services, so the fact ODF is free, 
while OOXML belongs to MS, forcing you to use their products, has no 
great influence in IT decisions). Error prevention and preventing losses 
due to such errors, is however something very differently, that hits a 
business directly in its central plexus.

Bryce L Nordgren wrote:
> I'm not suggesting that now is the time to deal with the issue in full.
> However, I wish to express my heartfelt opposition to allowing application
> authors to drive the standardized expression of something already agreed
> upon for decades by such organizations as ISO, NIST, and the national
> standards bodies of most (all?) countries.

I also strongly oppose letting developers drive the standardisation for 
something  that is already standardised. From personal experience with 
implementing standards (in a rather different field), I fear that any 
attempt to standardise something after it was already implemented in a 
number of different and inconsistent ways (and therefore likely wrong) 
is doomed to failure. As this needs additional ODF-changes, I express my 
heartfelt opposition to let ordinary people do it. Most would regret it 
later. Correcting all the errors will be a slow and painful process.

3. TOP 5 of Major Design  Flaws (in existing spreadsheet applications)
On a side note, I have begun filing issues on the OOo site in this series.

One issue deals with typing/units.

Another issue deals with duplicate data and propagation of errors due to 
such duplicate errors,
see http://www.openoffice.org/issues/show_bug.cgi?id=80139  and the 
blocking issues for that issue.

I have not filed yet my other TOP 5 issues, but these include 
multidimensional spreadsheet  functionality (like default formulas per 
column and real multidimensional data) and a complete restructuring of 
the spreadsheet (most programming languages, like C and C++, and 
programming environments, like MS Visual Studio and many others have 
characteristic *functional areas*, like headers, separate debugging 
windows and so on. Spreadsheets are the only one to perpetuate the 
spaghetti coding technique and mix everything up in one table (data, 
formulas, results, names and descriptions, ...).

I hope to find some time during the next days to file the feature 
request for multidimensional spreadsheets/default formulas (and sometime 
later the others, too).



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