[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [office-comment] DISTINCT Values
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 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!