Requirement - reinvent the spreadsheet

["Joe Raftery" <JoeRaftery@hoarelea.com>]

+NAME
Joe Raftery

+CONTACT
Joe.raftery@gmail.com

+CATEGORY (select one or more from below)
formatting

+SCOPE (select one or more from below)
text/spreadsheet/presentation

+USE CASE
We use spreadsheets for presentation and they are not good at that.

We create a little table - columns for each data type. Column for 
calculated results on the right, calculated based on the data columns on
the left.
We add a row at the top for column names.
We add a row at the bottom for totals.
We add some more rows at the top for a heading so it looks better.
We add a parameter we might want to change and put it off to the side.
We add some more calculations on the bottom to process the totals and
complain that
the column width doesn't work with this bit.
We come back a month later and change a number and get the wrong answer 
and it takes a week to find where we made the mistake.

Let's rethink the spreadsheet. 
What if a spreadsheet is reduced to a simple table embedded in an ODF
page that
contains lots of these tables.
The column names are not just letters they can be the actual column
names. 
Other parameters that don't belong in the table are elsewhere on the
page. 
They have names that we can reference in formulas. 

+DESCRIPTION
This is not just an implementation issue. There are a number of aspects
that 
can be helped with markup.
Column and row names and can be specified as any arbitrary value -
"Sales" or 
"Profit" or "Hours" or "January" so a cell can be "January.Sales".

Formulas can be applied to an entire column rather than using formulae
with 
wildcards and copying down. E.g. "Profit"="Sales"-"Costs" where
"Profit", 
"Sales" and "Costs" are column names.

Summary rows with subtotals can have a special status so they are not
really 
part of the table and the 'column' formulae don't apply to them. These
would be 
linked to a 'group of rows', a concept that you already have in ODF.

Miscellaneous other parameters can be placed outside the table but
easily 
referenced and used in calculations. E.g. "Cost inc Tax" = "Cost" * (1 +
"Tax Rate")
where "Cost inc Tax" and "Cost" are column names and "Tax Rate" is a
parameter 
given elsewhere in the document but not in the table.

Standalone parameters could also be used for the sort of post processing
we put 
below the table in our spreadsheets.

I know this is starting to look more like a database but maybe that
isn't necessarily 
a bad thing. It will make importing from and exporting to databases more
straightforward.


Does this make sense?.



This email (and any attachment) is intended only for the attention of the addressee. It is STRICTLY CONFIDENTIAL and may be legally privileged. If you have received it in error any disclosure distribution or copying of all or any part of the contents is prohibited. While virus checked by Hoare Lea, the recipient remains responsible for the consequences of any virus received.