Re: [office-formula] Semantics

[Dan Bricklin <danb@bricklin.com>]

In my example, where "2006" is a label, the average user may not 
think of it as a number. How can we determine that? Text (even that 
which looks like a number) may be left justified and numbers right.

I think the definition of how user input is converted into storage 
format is not something we are doing here. That is UI. (Are we 
defining how popup calculator pads work on pen-based systems?) The 
values are already in a formula. We are talking about formula 
interchange and we can be stricter about formatting values in a way 
that shows the type. After all, our cell reference format is almost 
certainly not the one we'll show to users.

Auto conversion is tough. As things proliferate (date formats, 
"Q1'2006", colors, etc.) you run into problems where you have to 
choose between 6 of one or half a dozen of the other - there is no 
"right" answer.

COUNT and COUNTA do different, common operations for two different 
types of uses of a list of data. One is good for data that doesn't 
distinguish between type, just presence or not (apartment number -- 
which can include "109a"), and the other is used in math 
(SUM(range)/COUNT(range)). I think we will run into a variety of such 
things as we think about data types.

I find it strange that the OpenFormula spec has text but not rich 
text. How are we handling that? Any modern product really needs to 
deal with that. What about HTML or a DOM fragment? Those are good 
things for thinking about making this more future-proof as well as 
how to handle old things like numbers and text.

To this and Rob's comment about goals: I think a major use of ODF 
will be in the interchange of subset products -- simple list 
managers, rich text in the middle of an application that does other 
things, etc. We have to be careful about assuming the user's model of 
the data nor the restrictions put on the UI. The ODF spec, as I 
recall, allows quite complex tables, more so than most simple data 
managers or many spreadsheets. Not everything will convert well. We 
need to make it easy for the lesser products to gracefully degrade 
and indicate where the deficiency is. Stronger typing helps here. I 
makes it easier to flag problems (and test). Testing for "I don't 
know about complex" is a lot easier than testing all the conversion options.

-DanB

At 08:43 AM Tuesday 2/28/2006, Tomas Mecir wrote:
>On 2/28/06, Dan Bricklin <danb@bricklin.com> wrote:
> > I can see why you'd want COUNT vs. COUNTA -- define a range bigger
>
>The problem with COUNT/COUNTA: what if a cell contains a string that
>can be converted to a number ? Say, "3". What then ? With this
>approach, COUNT doesn't include this, but your average user will say,
>but it's a number.
>
>Another question is, do we even WANT to delve into problems like this
>? Or shall we simply choose the approach which is currently used most
>?
>
>I think this introduces the problem of our goal: shall we design a
>spec based on real spreadsheets, or also put in new/changed things, if
>we feel that it makes sense ?
>
>/ Tomas