Re: [office-comment] Data Type Specification and Conversion likein FORTRESS

[Patrick Durusau <patrick@durusau.net>]

Leonard,

First, thanks for all the comments! They are very helpful.

Sanity check: What you are asking for is different from 8.5.3.2 
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!

Patrick

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.
>
> Kind regards,
>
> Leonard Mada
>
> 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
>
>
>

-- 
Patrick Durusau
Patrick@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!