OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

office-formula message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [office-formula] Chapter 4 Types


Eike,

What I would like to avoid is re-defining any datatypes. For several 
reasons:

1) Good standards rely on other standards that have already defined 
things they can use.

2) We don't have to worry about making any mistakes in the defining of 
those datatypes.

3) We don't have to spend time and space on repeating what has already 
been defined.

I mentioned those two standards not as an exclusive list but to 
illustrate that this is not an area devoid of prior work.

As I said in my other post, I think defining string representations for 
datatypes is a good idea. I don't see that as having anything to do with 
the datatypes that are accepted by a function, for example.

For example, we don't want division limited to integers. Fine, define 
the acceptable inputs to the division operator to be real numbers. End 
of issue. We need say no more than that. (Well, yes we have to account 
for division by zero, etc., but defining the datatypes for the inputs 
avoids having to say anything about integer division.)

Closer/further away?

Hope you are having a great day!

Patrick





Eike Rathke wrote:
> Hi Patrick,
>
> On Tuesday, 2009-01-20 14:32:26 -0500, Patrick Durusau wrote:
>
>   
>> Second, I think a much shorter, say a paragraph at most, discussion of  
>> what lies within this chapter is more than sufficient. As written it  
>> defines (or appears to define) rules for values, references, etc. All of  
>> that can be done but needs to be done where appropriate. 
>>
>> I think part of my uncertainty is that most of this has been defined  
>> before. The W3C Schema datatypes come to mind.  
>> (http://www.w3.org/TR/xmlschema-2/)
>>     
>
> These may be helpful in some cases, but would need close inspection in
> detail. For example, our Number type essentially is
> http://www.w3.org/TR/xmlschema-2/#double but the restriction of the
> canonical representation does not apply.
>
> http://www.w3.org/TR/xmlschema-2/#string may be suited as well, but
> http://www.w3.org/TR/2000/WD-xml-2e-20000814#dt-character excludes some
> control characters and characters from the surrogate blocks (btw, why is
> that?) that are not illegal in spreadsheet string context, see "5.4
> Constant Strings".
>
>   
>> Or, ISO/IEC 11404:1996  
>> (http://std.dkuug.dk/JTC1/SC22/WG11/docs/iso11404.pdf)
>>     
>
> See below.
>
>   
>> (I am sure there are others, those just happen to be two that come to mind.)
>>
>> Granted there may be some datatypes that are not defined elsewhere that  
>> we need but shouldn't we limit ourselves to defining only those?
>>
>> Broader question: What impact would applying the datatypes as defined in  
>> ISO/IEC 11404:1996 have on the current function definitions? Are our  
>> current definitions far enough from those to cause problems?
>>     
>
> I don't see how the ISO 11404 definitions of datatypes and their
> literals and operations would help here. Do you have anything specific
> in mind?
>
>   Eike
>
>   

-- 
Patrick Durusau
patrick@durusau.net
Chair, V1 - US TAG to JTC 1/SC 34
Convener, JTC 1/SC 34/WG 3 (Topic Maps)
Editor, OpenDocument Format TC (OASIS), Project Editor ISO/IEC 26300
Co-Editor, ISO/IEC 13250-1, 13250-5 (Topic Maps)



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]