Leonard,
Leonard Mada wrote:
> Hi,
>
> Patrick Durusau wrote:
>
>> Leonard,
>>
>> Another interesting comment!
>>
>> Hmmm, but isn't it true that what OpenDocument should define are the
>> operators that work with DISTINCT (and other functions) such that you
>> can write your own functions?
>>
>> What concerns me is that no matter how large the eventual list, we
>> are going to miss that special function that someone has to have. If
>> we give them the ability to use standard operators with which to
>> write their specialized functions, that lessens the load on us and
>> gives users greater freedom.
>
>
> Unfortunately, I have a very different and justified opinion. Maybe I
> have some better understanding of spreadsheet use than many people on
> this list as I have both
> extensively used spreadsheets myself for working
> overlooked 100+ employees working extensively with spreadsheets
> extensively used spreadsheets in research settings
>
I don't doubt that you have extensive experience in using spreadsheets.
However, from my experience with standards it isn't possible to write a
standard based on the instruction: "Whatever functions are possible I
want them."
Mostly because that is an unbounded space and so even if I start with
where David and others are now, I have no way to know where to stop.
(The latter being something important to know when writing a standard.)
What we need are details. Use case scenarios are useful but only up to a
point.
For example, you mention the R as factor () below.
Recalling that OpenDocument is an *interchange* format, how do we deal
with the following issue?
> Factors are currently implemented using an integer array to specify
> the actual levels and a second array of names that are mapped to the
> integers. Rather unfortunately users often make use of the
> implementation in order to make some calculations easier. This,
> however, is an implementation issue and is not guaranteed to hold in
> all implementations of R. (Section 2.3.1 Factors, R Definition Language)
We do not specify implementation details so it is possible for an "as
factor()" function to work differently depending upon implementation
details.
Having a function defined by a standard work differently is a bad thing.
I don't know whether that would actually change the result of a function
or not but it is an example of the level of detail that is necessary to
consider when defining a function in a standard.
I suspect it would be possible to define "as factor()" such that it had
a standardized result and if someone allowed used based on
implementation details they would be non-conformant. I say that not
having looked at the details. And by details I do not mean use or test
cases but a formal definition of the function.
I know the formula SC has a number of functions that still need some
work so maybe we need a rule that welcomes new function proposals but
grants priority to requests accompanied by work on functions already
accepted for standardization.
David, what say you?
Hope you are having a great weekend!
Patrick
--
Patrick Durusau
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!
