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

 


Help: OASIS Mailing Lists Help | MarkMail Help

office-comment message

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


Subject: Re: [office-comment] DISTINCT Values


Patrick Durusau:
> 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.)

Right.  At this time, we've been focusing on interchange between EXISTING spreadsheet implementations. A function not in any implementation is obviously NOT needed for exchanging existing spreadsheets :-).  And frankly, by adding functions from many different implementations, we've ended up with a spec that merges the best innovations from many different implementations, so implementors will end up with quite an improvement.

That said, we are NOT opposed in principle to adding a few new functions.  But the group will need to agree to do so, which means arguing (1) they're really needed by users (the larger the group the better), (2) that their semantics can be fully and well-defined in the short time remaining, and (3) that they are obviously implementable (because an unimplementable standard is a DISASTER).  In particular, we have been working at this for several years, and we need to hurry up and complete something.  So a proposal with exact details on EXACTLY what the spec would say is MUCH more likely to get accepted at this point.

> What we need are details. Use case scenarios are useful but only up to a point.

Use case scenarios are useful for arguing that a particular function SHOULD be included.  But they are not enough to DEFINE the function by themselves.  Sample text to paste into the standard is MUCH more likely to get accepted.

> 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.

The problem is one of time; we have little time left before it MUST be done, and functions EVERYONE agrees must be in the spec MUST take precedence over those where there is no such consensus.  That said, I hate to have a hard-and-fast rule; if there's a key omission in capabilities, I really want it to have a fair hearing!  Just be aware that at this point, it needs to be a really good argument for its inclusion, and things that have broad impact are much less likely to be accepted at this point.

--- David A. Wheeler


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