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] Semantics


There are two things here (perhaps respond in separate emails to each to split the thread):

1. How to represent numeric and date types in the file format.

Solution, pick a format, move on - this shouldn't be controversial.
Propose:
C-locale for numbers - unless there is an ISO or some other standard.
ISO 8601 format for Gregorian dates - other calendars?
what others are needed? boolean

2. What to do with string data?

It must be stored 'as is' in the file format, but how to convert it to other types. This has no simple solution and this is where locale can come in. Should we consider making the file format locale aware? So VALUE("3,333.33") in the UI is saved as VALUE("3,333.33", locale). But what does the UI do with that? If the locale matches the machines locale, no problem. Otherwise handle as an unknown function, ignore the locale (i.e. similar to what happens now), retain locale information in the cells format string or warn the user about locale related issues?

Is this perhaps beyond the scope of the specification? The specification is about data exchange, by making the locale information part of the specification we enable this, otherwise we become immersed in a quagmire almost endless possibilities.

My fear is that by adding things like locale we move the specification too far away from current implementations and risk no one using it. On the other hand it is forward looking. What are spreadsheet implementers thinking of taking this in the future? We've had an insight into what Dan Bricklin is thinking.

--- Richard Kernick


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