Re: [office-comment] Unit system tracking

[Bryce L Nordgren <bnordgren@fs.fed.us>]

"David A. Wheeler" <dwheeler@dwheeler.com> wrote on 06/10/2007 08:37:08 PM:

> What's more, there are a HUGE number of "little details" that must
> be addressed, e.g., you need a standard way to associate various
> values with unit systems, standard ways to represent them,
> descriptions with each function on how to deal with them, etc.
> You'd need to able to say "I want this cell in furlongs/fortnight"
> without actually entering the number, for example.  I'd guess it'd
> take a LOT of effort to spec all that, plus implementation work to
> make sure that the specification was actually correct.  The history
> of past systems that tried to do this is not encouraging. I remember
> a number of Ada95 automatic unit systems that came unglued when
> people tried to use them seriously.  The _idea_ is obvious enough,
> but really getting the details right is difficult.. it's amazing how
> much humans do "automatically" but is hard to get down in a real
> spec.  And if they're done wrong it's WORSE than useless, because
> you'll pay the performance and implementation costs, and then have
> to work around it.  And users who do NOT want it would still pay the
> price, which is a problem too.  There's no point in spec'ing this
> unless it's CORRECT.

There are many people working on (or have worked on) this in various
contexts, almost none of them are spreadsheets.

A simple system, like the data model specified in ISO 19103, is fairly easy
to encode into XML (ISO 19136).

You could look at the data model which started in the Java Specification
Request (JSR) 108, and which is now being continued in JSR-275 (
http://www.jcp.org/en/jsr/detail?id=275).  This is from the JScience
package and is pretty mature.  There is a means to specify desired units,
and it may even be internationalized (?).

I do not think it is trivial, but I do not think is would be wise for this
effort to start from scratch either.  At the core, you are defining a new
data type (a "Measure") which may be present wherever "Numbers" are now.
The current "Numbers" become "Scalars" and are retained.  The obvious rules
apply.  You will be stealing or creating a system to uniquely encode units
(as text strings and as XML), and this encoding is used in conjunction with
Measures as well as in cell/field/form formatting expressions.

I do not think users who do not want it will pay any price.  The current
"number" must be retained for backwards compatibility and can be handled
however it is handled now.  Think of it more as adding a data type and
defining rules for the interaction of the new data type with itself and
with the currently existing type.

$0.02
Bryce
PS: Before hitting "send" I did a quick search.  It appears that ISO
15939:2002 lays some groundwork.  Hard to say because there's no abstract
on the ISO site and I didn't buy it.  (
http://www.iso.org/iso/en/CatalogueDetailPage.CatalogueDetail?CSNUMBER=29572&ICS1=35&ICS2=80&ICS3=)
  But there's a summary on another page (
http://standards.computer.org/sesc/s2esc_pols/FP-05_Software_Measurement.htm)
  Units would seem to be a "Special case" of the notion described therein.