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


Help: OASIS Mailing Lists Help | MarkMail Help

office-formula message

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

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

"David A. Wheeler" <dwheeler@dwheeler.com> wrote on 07/01/2006 08:44:06 PM:

> 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!  And there's more,
> see below for some of the comments.

> 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.

I'd rather be unambiguously dangerous than just ambiguous.  If we want to simply document Excel's current behavior with conversions, that is fine with me. Not my preference, but acceptable.  We're talking about danger here, a degree of risk, but not absolute failure.  We can rely somewhat on user intelligence, but also on future to-be-coded proofing tools that could check a spreadsheet for possible errors of stylistic problems of this nature, something like an odf-spreadsheet-lint.


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