From koffice-devel Tue Jun 12 07:45:47 2007 From: Thomas Zander Date: Tue, 12 Jun 2007 07:45:47 +0000 To: koffice-devel Subject: Re: Fwd: [office-comment] Data Type Specification and Conversion like Message-Id: <200706120945.48053.zander () kde ! org> X-MARC-Message: https://marc.info/?l=koffice-devel&m=118163438625141 MIME-Version: 1 Content-Type: multipart/mixed; boundary="--===============0863432056==" --===============0863432056== Content-Type: multipart/signed; boundary="nextPart4639796.1aq19Sar63"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit --nextPart4639796.1aq19Sar63 Content-Type: multipart/mixed; boundary="Boundary-01=_s8kbGUf5FzAL1FY" Content-Transfer-Encoding: 7bit Content-Disposition: inline --Boundary-01=_s8kbGUf5FzAL1FY Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Here is an evenly interresting answer (attached) from the guy that is deep= =20 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=3Dunitsml). = =20 > If we want to add units support to spreadsheets in the future, then > this project might help with some basic representational issues. =2D-=20 Thomas Zander --Boundary-01=_s8kbGUf5FzAL1FY Content-Type: message/rfc822; name="forwarded message" Content-Transfer-Encoding: 7bit Content-Description: "David A. Wheeler" : [office-comment] Unit system tracking Content-Disposition: inline Return-Path: 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 ; 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 ) by smtp15-01.prod.mesa1.secureserver.net (qmail-ldap-1.03) with SMTP for ; 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 ) by pre-smtp17-01.prod.mesa1.secureserver.net (qmail-ldap-1.03) with SMTP for ; 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: List-Help: List-Unsubscribe: List-Subscribe: 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" 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: 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 cod= ing capabilities to explicitly state the type of the values. This *major de= sign flaw* of spreadsheets makes them very error prone when intermingling = various data formats. > I really miss something like the new FORTRESS (see http://fortress.sunsou= rce.net/). >In my primary work, I am overseeing 100+ employees working extensively wi= th worksheets. Unfortunately, there were often situations where 2 currenci= es 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-'80= s 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: =3D SUM(A1:A3) =3D> implicit conversions are done >2nd example: >A1: 1.2 M Euro >A2: 0.67 M $ >A3: =3DSUM(A1:A2) =3D> implicit conversion using a pre-specified conversio= n rule >As this feature will differentiate the flawed concepts of the past from th= e 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 syst= em conversions already, though not automatic in the way you'd like. The cu= rrent specification includes a function, CONVERT, that does unit system con= versions for many (constant) relationships. Note that the CONVERT specific= ation goes WAY, WAY beyond what Excel does - it can handle areas (like acre= s), velocities (like mph and m/s), lightyears, and many other useful units.= So we _already_ do unit system conversions, but don't require application= s 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 an= d conversion". Automatic unit system tracking and conversions are indeed a useful capabili= ty, and there are a very few calculation systems that do automatic unit sys= tem 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 advantage= s. Unfortunately, really doing this correctly for ALL cases is actually ve= ry, very complicated. Truly handling monetary system conversions is an incr= edibly complicated issue; you need to provide control over this. And somet= imes 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 u= sers of BIG spreadsheets would be very UNHAPPY with this as a requirement. = And it greatly complicates implementation, too, which creates a big opport= unity cost. What's more, there are a HUGE number of "little details" that must be addre= ssed, e.g., you need a standard way to associate various values with unit s= ystems, 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 i= n 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 wo= rk to make sure that the specification was actually correct. The history o= f past systems that tried to do this is not encouraging. I remember a numbe= r of Ada95 automatic unit systems that came unglued when people tried to us= e them seriously. The _idea_ is obvious enough, but really getting the det= ails right is difficult.. it's amazing how much humans do "automatically" b= ut is hard to get down in a real spec. And if they're done wrong it's WORS= E 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 stil= l 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 track= ing, due to these problems. There's a need for an interchange standard for= current apps that do NOT perform this automated tracking, so MANDATING suc= h support on EVERY spreadsheet application would (in my opinion) be inappro= priate. That said, OpenDocument is carefully designed to allow OTHER formula langua= ges as well. It would be quite reasonable to define another formula langua= ge that was "this one, plus automatic unit system tracking". Of course, yo= u'd then need to do all the work to define what the tracking/conversion act= ually added (big deal!). So I think we should define a language without automatic unit system tracki= ng 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 de= tails 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 peop= le interested in such follow-on work to support automatic unit system track= ing and conversion, I'd like to know; you'd need to promise significant tim= e 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 stan= dardizing 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=3Doffice --Boundary-01=_s8kbGUf5FzAL1FY-- --nextPart4639796.1aq19Sar63 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD4DBQBGbk8sCojCW6H2z/QRAsLxAKDjuKMABUwyXiCMWM+id3EmVZxV6QCXY8qy vNCOs7OfTmIq8/TITD3r8A== =tZOf -----END PGP SIGNATURE----- --nextPart4639796.1aq19Sar63-- --===============0863432056== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ koffice-devel mailing list koffice-devel@kde.org https://mail.kde.org/mailman/listinfo/koffice-devel --===============0863432056==--