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] Conversions (BIN2DEC and friends) - how muchto spec?


Rob Weir:
> Are these functions [BIN2DEC etc.] assuming a particular
> byte ordering?  Or are the machine-dependent?

No, they don't assume a particular byte order.
They're still AWFUL.

Andreas J Guelzow said:
> At least the Gnumeric developers believed it necessary
> to implement the same syntax as Excel to allow users to
> easily migrate from Excel to Gnumeric. I would assume that
> something similar is true for OOo.

Actually, OOo uses a SLIGHTLY different display syntax; it uses
";" as the parameter separator.  For internationalization this
is very sensible; your decimal separator can be "." or ","
and there's no ambiguity.  But that's a nit. Basically, I agree with
you, applications tend to agree on syntax (that's a GOOD thing!).

And as you noted, what matters is that we can exchange data.
KSpread uses "==" instead of "=" for "is-equal-to".
Corel Quattro Pro has "skins", which let you PICK the display/data
entry syntax. As long as we agree on how to share data,
the display format is less important.

> Of course for the Openformula file format it is, imho,
> more important to make sense...

Yes.

I said:
>> We have three choices that I can see:
>> 1. Don't include them in the spec.  Clean, but then we don't
>>    provide an upgrade path...
>> 3. Include them, including the weird semantics that everyone
>>    implements (and people probably depend on),
>>    but also include "nicer" functions with
>>    saner semantics....


>I would prefer #1. If we indeed want to do number 3 we should use a
>different namespace for them akin of
>
>DEPRECATED.BIN2DEC("101") or
>NONSENSE.BIN2DEC("101")

That'd be plausible. I like the idea, though not the example names:
* NONSENSE describes how I feel, but I think we should be
  not quite so vindictive in the official name.
* And over time, other functions we now think are marvelous
  might be deprecated.  I don't think we should call it
  "DEPRECATED", because there will someday
  be deprecated functions that aren't in that group.

How about LEGACY? E.g., "LEGACY.BIN2DEC...".
The LEGACY group would be a set of functions from older
spreadsheets that COULD be implemented as an aid in
transitioning to OpenFormula from non-OpenFormula...
not a group for all deprecated functions.
We could then not _mandate_ support
for them... but if you DO support them, here is their syntax.
I doubt "LEGACY" will ever become a top-level-domain name in DNS.

>Realistically, they come from Excel so 
>COM.MICROSOFT.BIN2DEC("101")
>would make more sense but of course we should not define
>functions in that namespace.

I also would prefer not to.  If it's sensible we COULD do so;
they are, after all, in Excel.  It's not clear to me that
they originated in Excel, though; I haven't tracked down their
history to determine the guilty party.

Anyway, I think we should define a different space like
LEGACY.  That would help, and avoids defining someone
else's namespace.  And not all LEGACY functions will come
from Excel :-(.

--- David A. Wheeler



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