Re: [office-formula] Our next adventure: Types and conversions

["David A. Wheeler" <dwheeler@dwheeler.com>]

A while back I posted a request to discuss typing issues.
BTW, although I _take_ private email,
I'd really prefer that people posted publicly...
people cannot publicly reply, and nothing will change in the
spec if it doesn't come out publicly :-) .

The "logical" type seems to be sorted out fairly easily -
option "C" seems to be the one people can agree on. That means that
in the spec we can describe a logical type, but clarify that
(1) it can be IMPLEMENTED using simply the numeric type,
instead of REQUIRING a distinct logical type,
(2) PERMIT a distinct logical type, and
(3) auto-convert... if you expect a single number, and get a
distinct logical type, auto-convert to 0 and 1.  If you expect
a logical and get a number, auto-convert as well.

The text/numeric issue was known to be thorny, and
look... it is!   We do NOT have consensus on any particular
approach.  I think I understand WHY people have their
different viewpoints.  But it is quite possible that we
will never come TO a consensus, and we need to make sure that
this does not hold up the rest of the work (more than it has).
Those who primarily value Excel compatibility want to do
automatic text-to-number conversion.  Yet that is almost
insane when trying to share spreadsheets between locales... and
most expect cross-locale sharing to increase, not decrease.
Most implementations convert to 0, which is at least locale-
insensitive, but it also can silently propogate errors.
"Error" is the safest value for an implementation, but I don't
hear many wanting to MANDATE that either!  Etc., etc.

Clearly it would be better to have an agreement on what
happens when text and numbers are combined, because then
naive users who do that can be assured that their spreadsheets
"work everywhere".  But that assumes that a single answer
can be agreed on.  It is worthless to write a spec that people
will NOT implement, and given the passion of some viewpoints,
I think that is a significant risk.  And we certainly don't
want to mandate an approach that in retrospect is found "wrong".

So the obvious question to me is, "can this spec
be useful at all without
choosing any particular approach?"   I believe in this case
the answer is "yes", at least for the first version of the spec.
People can simply always use numbers as input to other numbers;
this is what most people do, and that ALWAYS works.   Creating a
"VALUEL(text [; locale])" function would address other cases and
is probably a good idea, though it'd be a
committee invention and those always worry me.

We need to MOVE ON.  So here's what I suggest...

For NOW, we won't require any particular text/number conversion
algorithm, and we'll be clear that we won't.  That doesn't mean
the final spec will allow all options; anyone can still
raise the issue here in this forum, let's continue discussion.
If we CAN find a consensus that is more specific, GREAT!!!
But if not, users can still create spreadsheets that exchange
easily, they just need to not mix text/numbers. And remember, this
is only round one -- many specs add specificity as time goes
on (and as certain areas that were once controversial gain clarity).

But we need to work on other things too.
Given a lack of consensus on any
particular algorithm/approach, I think we should simply document
that a range of options are allowed in this version of the spec,
until we can agree on something better.  If we can agree on
something better before we deliver the document to the
ODF committee, great!!  But let's not hold up the
rest of things trying to gain agreement, which we may never get.

(BTW, I posted this twice earlier, with snippets from previous
posts, and it was silently dropped both times.  Hopefully
this version will get out to the mailing list.)

--- David A. Wheeler