[prev in list] [next in list] [prev in thread] [next in thread]
List: koffice-devel
Subject: Re: Fwd: [office-comment] Data Type Specification and Conversion like
From: Thomas Zander <zander () kde ! org>
Date: 2007-06-12 7:45:47
Message-ID: 200706120945.48053.zander () kde ! org
[Download RAW message or body]
[Attachment #2 (multipart/signed)]
[Attachment #4 (multipart/mixed)]
Here is an evenly interresting answer (attached) from the guy that is deep
into speadsheet formulas; David Wheeler.
also;
On Monday 11 June 2007 19:00:57 robert_weir@us.ibm.com wrote:
> Something to keep in mind is the Units ML work, started by NIST
> (http://unitsml.nist.gov/) and recently continued in a new OASIS TC
> (http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=unitsml).
> If we want to add units support to spreadsheets in the future, then
> this project might help with some basic representational issues.
--
Thomas Zander
["forwarded message" (message/rfc822)]
Return-Path: <SRS0ÄBj=LL=lists.oasis-open.org=office-comment-return-175-thomas.zander=OpenDocument.us@bounce.secureserver.net>
Received: from mx3.groni1.gr.home.nl ([213.51.130.141])
by mta3.groni1.gr.home.nl
(InterMail vM.6.01.04.03 201-2131-118-103-20050206) with ESMTP
id <20070611023804.LBDH6016.mta3.groni1.gr.home.nl@mx3.groni1.gr.home.nl>
for <zander@home.nl>; Mon, 11 Jun 2007 04:38:04 +0200
Received: from ktown.kde.org ([131.246.120.250]:35310)
by mx3.groni1.gr.home.nl with smtp (Exim 4.30)
id 1HxZn7-0002gF-Un
for zander@home.nl; Mon, 11 Jun 2007 04:38:02 +0200
Received: (qmail 7515 invoked by uid 1055); 11 Jun 2007 02:38:01 -0000
Delivered-To: kde.org-zander@kde.org
Received: (qmail 7512 invoked from network); 11 Jun 2007 02:38:01 -0000
Received: from unknown (HELO smtp15-01.prod.mesa1.secureserver.net) (64.202.189.203)
by ktown.kde.org with SMTP; 11 Jun 2007 02:37:59 -0000
Received: (qmail 10024 invoked by uid 1000); 11 Jun 2007 02:37:23 -0000
Delivered-To: thomas.zander@OpenDocument.us
Received: (qmail 10022 invoked from network); 11 Jun 2007 02:37:23 -0000
Received: from unknown (HELO pre-smtp17-01.prod.mesa1.secureserver.net) \
([64.202.166.71])
(envelope-sender \
<office-comment-return-175-thomas.zander=OpenDocument.us@lists.oasis-open.org>)
by smtp15-01.prod.mesa1.secureserver.net (qmail-ldap-1.03) with SMTP
for <thomas.zander@OpenDocument.us>; 11 Jun 2007 02:37:23 -0000
Received: (qmail 29475 invoked from network); 11 Jun 2007 02:37:23 -0000
Received: from unknown (HELO ms01.oasis-open.org) ([66.151.234.62])
(envelope-sender \
<office-comment-return-175-thomas.zander=OpenDocument.us@lists.oasis-open.org>)
by pre-smtp17-01.prod.mesa1.secureserver.net (qmail-ldap-1.03) with SMTP
for <thomas.zander@OpenDocument.us>; 11 Jun 2007 02:37:21 -0000
Received: from [10.0.0.2] (helo=mail.oasis-open.org)
by ms01.oasis-open.org with esmtp id 1HxZmP-0004Fq-7i
for thomas.zander@OpenDocument.us; Sun, 10 Jun 2007 22:37:17 -0400
Received: (qmail 2378 invoked by uid 508); 11 Jun 2007 02:37:16 -0000
Mailing-List: contact office-comment-help@lists.oasis-open.org; run by ezmlm
Precedence: bulk
List-Post: <mailto:office-comment@lists.oasis-open.org>
List-Help: <mailto:office-comment-help@lists.oasis-open.org>
List-Unsubscribe: <mailto:office-comment-unsubscribe@lists.oasis-open.org>
List-Subscribe: <mailto:office-comment-subscribe@lists.oasis-open.org>
Delivered-To: mailing list office-comment@lists.oasis-open.org
Received: (qmail 2362 invoked by uid 0); 11 Jun 2007 02:37:16 -0000
Content-Type: text/plain;
charset="iso-8859-15"
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
From: "David A. Wheeler" <dwheeler@dwheeler.com>
Reply-To: dwheeler@dwheeler.com
To: office-comment@lists.oasis-open.org,
office-formula@lists.oasis-open.org
CC: discoleo@gmx.net
Date: Sun, 10 Jun 2007 22:37:08 -0400 (EDT)
X-Sender: 258406
X-Mailer: RMM
Message-Id: <E1HxZmG-0005lt-J7@fenris.runbox.com>
X-Virus-Scanned: by amavisd-new-20030616-p10 at oasis-open.org
X-Spam-Status: No, hits=-1.4 tagged_above=-10.0 required=3.0 tests=AWL,
BAYES_05
X-Spam-Level:
Subject: [office-comment] Unit system tracking
X-AtHome-MailScanner-Information: Neem contact op met support@home.nl voor meer \
informatie
X-AtHome-MailScanner: Found to be clean
Leonard Mada proposed unit system tracking, here:
> A major disadvantage of every spreadsheet application is the lack of coding \
> capabilities to explicitly state the type of the values. This *major design flaw* \
> of spreadsheets makes them very error prone when intermingling various data \
> formats. I really miss something like the new FORTRESS (see \
> http://fortress.sunsource.net/). In my primary work, I am overseeing 100+ employees \
> working extensively with worksheets. Unfortunately, there were often situations \
> where 2 currencies were used, providing a perfect milieu for conversion errors, \
> e.g. 1,000,000 RON equals approx. 300,000 Euro, BUT adding 1,000,000 or 300,000 \
> makes a great difference (of 700,000 RON or Euro). The globalisation trend will \
> only foster this development. The killer feature that will differentiate \
> spreadsheets from the '70-'80s from modern concepts would allow the user to \
> specify the type of the data, e.g.:
> A1: 30 m
> A2: 125 cm
> A3: 86 inch
> A4: = SUM(A1:A3) => implicit conversions are done
> 2nd example:
> A1: 1.2 M Euro
> A2: 0.67 M $
> A3: =SUM(A1:A2) => implicit conversion using a pre-specified conversion rule
> As this feature will differentiate the flawed concepts of the past from the modern \
> views, I hope that it gets implemented in the ODF specification.
Thanks for your helpful comments!
Unit system conversions are indeed very useful. We _do_ provide unit system \
conversions already, though not automatic in the way you'd like. The current \
specification includes a function, CONVERT, that does unit system conversions for \
many (constant) relationships. Note that the CONVERT specification goes WAY, WAY \
beyond what Excel does - it can handle areas (like acres), velocities (like mph and \
m/s), lightyears, and many other useful units. So we _already_ do unit system \
conversions, but don't require applications to track units with every value. It \
doesn't do currency conversions, as well. Let's call what you'd like to see \
"automatic unit system tracking and conversion".
Automatic unit system tracking and conversions are indeed a useful capability, and \
there are a very few calculation systems that do automatic unit system tracking and \
conversion. One of them is the Google calculator; if you type into the Google search \
bar "3cm + 1inch" it will correctly convert and give you the answer.
I looked into doing this briefly a while back, because it has its advantages. \
Unfortunately, really doing this correctly for ALL cases is actually very, very \
complicated. Truly handling monetary system conversions is an incredibly complicated \
issue; you need to provide control over this. And sometimes you do NOT want to \
follow the rules (some engineering 'rules of thumb' actually VIOLATE unit systems). \
Handling unit systems doesn't come for free; it generally causes a major performance \
loss (slowing calculation WAY down) which may or may not be okay depending on your \
circumstance - many users of BIG spreadsheets would be very UNHAPPY with this as a \
requirement. And it greatly complicates implementation, too, which creates a big \
opportunity cost.
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.
Current spreadsheet applications do NOT perform automatic unit system tracking, due \
to these problems. There's a need for an interchange standard for current apps that \
do NOT perform this automated tracking, so MANDATING such support on EVERY \
spreadsheet application would (in my opinion) be inappropriate.
That said, OpenDocument is carefully designed to allow OTHER formula languages as \
well. It would be quite reasonable to define another formula language that was "this \
one, plus automatic unit system tracking". Of course, you'd then need to do all the \
work to define what the tracking/conversion actually added (big deal!).
So I think we should define a language without automatic unit system tracking and \
conversion, and then, if enough people are interested in creating a specification for \
the automatic version, let them work on it as a follow-on project! But it would \
require a committed group of people to write the details of the specification AND to \
actually implement that spec. There's no point in writing a spec that people will \
not implement. If there are people interested in such follow-on work to support \
automatic unit system tracking and conversion, I'd like to know; you'd need to \
promise significant time to get all the details correct, and in practice you should \
arrange for at least one implementation before it can be standardized (else you risk \
standardizing something unimplementable).
--- David A. Wheeler
This publicly archived list offers a means to provide input to the
OASIS Open Document Format for Office Applications (OpenDocument) TC.
In order to verify user consent to the Feedback License terms and
to minimize spam in the list archive, subscription is required
before posting.
Subscribe: office-comment-subscribe@lists.oasis-open.org
Unsubscribe: office-comment-unsubscribe@lists.oasis-open.org
List help: office-comment-help@lists.oasis-open.org
List archive: http://lists.oasis-open.org/archives/office-comment/
Feedback License: http://www.oasis-open.org/who/ipr/feedback_license.pdf
List Guidelines: http://www.oasis-open.org/maillists/guidelines.php
Committee: http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=office
[Attachment #8 (application/pgp-signature)]
_______________________________________________
koffice-devel mailing list
koffice-devel@kde.org
https://mail.kde.org/mailman/listinfo/koffice-devel
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic