Re: [office-formula] CONVERT

[Eike Rathke <erack@sun.com>]

Hi David,

On Wednesday, 2007-02-07 15:06:22 -0500, David A. Wheeler wrote:

> > > I'd prefer calling a general money-conversion function CONVERT_MONEY
> > > instead of CONVERT_UNIT, and limiting CONVERT_MONEY to money.  "UNIT"
> > > is too generic, and makes you think of meters, etc.
> 
> Eike said: 
> > Actually that's what it can be used for in OOo too, hence I proposed
> > that name. We distribute OOo preconfigured with the fixed Euro currency
> > conversion factors, but the user is free to add any pair of units he
> > likes to the confguration. The mechanism of a shared configuration also
> > enables an enterprise to adapt rates at a central location. I'm pretty
> > convinced that this isn't used for anything else than money exchange
> > rates, but you never know..
> 
> I can't find any documentation about this in the Help files for OOo.  Can you point me somewhere?

Hmm.. strange, the online-help for CONVERT doesn't mention it at all,
not sure if it did in an earlier release. The function wizard says
"Converts a value according to a conversion table in the configuration
(calc.xml)." Actually the file name is different nowadays and the
description needs an update, there's already an issue for that.

> > CONVERT_ANY ? ;-)
> > 
> > Given the user-definable units it comes pretty near to how the function
> > actually is semantically defined.
> 
> Hmm, I like CONVERT_ANY as a name.  CONVERT already converts units, and EUROCONVERT has a fixed set of operations.
> 
> But what are its semantics? I guess it's:
>  * Look up in a special table for conversion info
>  * If fail, try EUROCONVERT
>  * If fail, try CONVERT... else Error.

Currently there is no fallback implemented, only the configuration table
is tried. But I actually like the idea of semantically providing
a fallback to the functions mentioned, in that particular order.

> But shouldn't we specify how the table itself is found?  And how do
> you portably exchange this information?

This is another problem. The conversion data is not yet part of an ODF
document, and I'm actually not sure how it could be accomplished. It is
not clear what should take precedence then, the document's table or the
configuration's table. There are use cases for both, and there are also
reasons to have it controlled either by the document or the application
respectively its user.

> I'm wondering if we shouldn't do that this go-round.  We already have
> various lookup functions, which would mostly do this job, and I fear
> that trying to specify how this exchange table is handled is suddenly
> a big addition.

Indeed, it would be a bigger addition to ODF. I guess we'd have to
discuss that on the TC level, but first develop some strategy regarding
different use cases. I suggest to postpone this aspect until we're done
with the rest of our ODFF definitions to get more important things done
first, but inform the TC that maybe there's something to come. However,
we may be too late in time to get that in for the v1.2 review phase.

  Eike

-- 
Automatic string conversions considered dangerous. They are the GOTO statements
of spreadsheets.  --Robert Weir on the OpenDocument formula subcommittee's list.