[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [office-formula] Grouping functions and capabilities
Robert Weir said: > > I guess I'm not convinced that classifying the functions, by whatever means, > > changes anything. I agree that profiling doesn't solve the universe's problems, but I still think it's useful. I propose that we give it a try, and go from there. If it's worthless, that'll become obvious. > > As a user, if I want to use a FOO() in my spreadsheet and > > it isn't there, then the fact that the spreadsheet was rated "Level 1" is > > little comfort. > > I don't have my FOO() and I want FOO(). Ah, but "level 1" didn't include FOO(). If you wanted FOO(), you would've picked an application that supported "level 3" (which let's say has FOO) or at least "level 1 + FOO". This should make it easier for you to choose an application that supports what you need, which is the point of a profile. In practice, nobody wants to test an app for every function; they want a convenient shorthand like "meets level 2" or "meets level 2 + financial_4" so they'll pick the right application. This can apply to an individual, or to a company/government/organziation... if they want a full-function spreadsheet application, it'll be easy to winnow out the 5-function applications. > > Ditto for if I do > > save my spreadsheet from an editor that has this function but then it is > > loaded my someone who doesn't have it. Ah, but it works the other way too. Often there are several ways to do something.... one may be widely portable (using only level 1 functions), while the other may not be. If I have a way to KNOW that, then I can stay in the straight-and-narrow and use the more portable approach. For example, Excel lacks the ARABIC() function, a function widely supported elsewhere... knowing that this function is NOT supported everywhere might convince you to do something else instead. There are other reasons for US to do profiling: 1. By identifying what's "most important/common" first, we force ourselves to work on the most important and most common functions first, wringing out their exact semantics. Yes, ARABIC() is a nice function, but let's talk about SUM() first, shall we? 2. By identifying what's "most important/common" first, we help implementors determine what's more important... and make sure that they get that implemented first. We have ALREADY had a significant impact on existing implementations, particularly KOffice and wikiCalc. The KOffice folks have been using our draft test spreadsheet to find and fix problems... not because there's a mandate to do so, but because it helps them to focus on the most important issues for real users, using small test cases that are easier to work with. Similarly, though wikiCalc is not trying to implement ALL functions, it's implemented all of the old level 1 functions... because it wasn't as hard to do that smaller set, AND because it results in MOST data files being portable. Tomas Mecir said: > Well, the thing is, the only solution to this would be requiring all > spreadsheets to implement all possible functions, and at the same > time, prohibiting them from implementing anything more. Which, > obviously, is not a good idea. > > I personally like this LOGICAL_1, ... approach, it makes it relatively > easy to check for level of compatibility, and allows incremental > updating to be more and more compatible with the spec - for example, I > can have all Level 1 functions fully complaint, and most higher ups > present, but occasionaly giving different results for whatever reason. > > And, yeah, if agreeing on levels/groups is a problem (although I don't > see why), let's just move on to defining each function and worry about > groups later on. Probably the biggest risk is spending too much time on "what level is this in", as opposed to defining it. But we're all grown-ups here, and I think a rough consensus on grouping/leveling will be sufficient for the purpose. I have used a very simple metric - "how many different implementations support it", with each implementation having a "vote" on importance. I think this metric is justifiable - if more apps implement a given function, then clearly it's more important. --- David A. Wheeler
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]