|Subject:||Re: [office-comment] Data Type Specification and Conversion likein FORTRESS|
|From:||Patrick Durusau (patr...@durusau.net)|
|Date:||Jun 7, 2007 3:45:13 pm|
First, thanks for all the comments! They are very helpful.
Sanity check: What you are asking for is different from 220.127.116.11 Condition, where a condition is set to test the validity of the entry in a cell. Yes?
In other words, you want to be able to declare a type for the data in a cell, separate and apart from a validation test on the content. Yes?
Such that I could enter a value, assume the data type is complex number and there is no validation condition set so I could (mistakely) enter: 5.
It would have the correct datatype but unless I set a validation condition, the user error will go undetected.
Or, are you asking that datatypes be associated with cells and I could either turn validation on or off? (Assuming I have supplied the validation tests for any datatypes not defined by OpenDocument.)
Hmmm, how many datatypes do you think OpenDocument should define along with validation tests versus those that we allow to be user supplied along with any validation test?
Hope you are having a great day!
Leonard Mada wrote:
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.
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: offi...@lists.oasis-open.org Unsubscribe: offi...@lists.oasis-open.org List help: offi...@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
-- Patrick Durusau Patr...@Durusau.net Chair, V1 - Text Processing: Office and Publishing Systems Interface Co-Editor, ISO 13250, Topic Maps -- Reference Model Member, Text Encoding Initiative Board of Directors, 2003-2005
Topic Maps: Human, not artificial, intelligence at work!