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

[Leonard Mada <discoleo@gmx.net>]

Hi,


Patrick Durusau wrote:
> 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?

Unfortunately, I did not find this section 8.5.3.2 in the ODF-document I 
have. However, I most definitely described something else.

Actually, I was referring at the  FORTRESS programming language 
developed by Sun Microsystems, specifically:
 - the  possibility to use various dimensions in cells AND
 - that the spreadsheet application  performs implicit conversions of 
these dimensions

e.g. we may enter in column 'A' the length of some objects:
A1: 1 m
A2: 27 cm
A3: 99 inch
A4: = SUM(A1:A3)
and the spreadsheet application would perform the implicit conversions 
and calculate the accurate result.

FORTRESS goes even further, e.g.:
we may divide the length by a time value, and get a velocity-measure

An extension would be to have user defined measures supporting variable 
conversions. Suppose, we build a spreadsheet, which will be used to 
enter various currencies: both Euro and US Dollars. So, we may want to 
sum up this column. First we define an explicit conversion between 
currencies (e.g. 1 Euro = US $ 1.27) and let the spreadsheet handle 
automatically the data accordingly. This conversion factor could be 
linked to an external foreign exchange rate.

Therefore, a user may enter US $ 4.5 M => and the spreadsheet would know 
that this means 4.5 Million US Dollars, which is equivalent to ~3.5 
Million Euro, making any automatic conversion when needed.

A full description of *Unit Conversions* is given in chapter 35 - 
Dimensions and Unit Declarations (p260) of the Project Fortress Language 
Specification (see http://research.sun.com/projects/plrg/fortress.pdf).

> 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.
5i => automatic conversion to the complex number (0 + 5 * i) ;-)
3m => size:3; internal unit type: distance as meters

This way, one would always know what is entered (it is 5i, or 3m, or 4.5 
Million Euros). Also, because conversions are done either explicitly  
(by some set rules) or implicitly, propensity for ERROR declines 
substantially. The spreadsheet application could easily highlight the 
type, similarly as FORTRESS will highlight the dimension/unit.

Sincerely,

Leonard

> 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