Re: [office-formula] Goals/levels/packaging/complex numbers

["David A. Wheeler" <dwheeler@dwheeler.com>]

robert_weir@us.ibm.com wrote:
> We're converging here.  This is good.
I agree!  In fact, I think this is a perfect example of how 
standardization should work... each one of us is raising different 
requirements and concerns, and we're all working to find a way to meet them.

> I agree we need to provide the tools needed to define profiles.  But 
> does this really require that we propose concrete profiles in the spec?
I think we must, because it's unreasonable to expect users to list in 
excruciating detail the capabilities they need every time.  But I also 
think we need to be very clear that those profiles are NOT the "last 
word" in profiles.  I think we can do that in the spec, as long as we 
clearly say that. Here's a go at it: "As a convenience, this 
specification defines packages of capabilities, which allow users and 
implementors to easily identify capabilities a particular document needs 
or an application supports. It even defines packages that include other 
packages, such as Desktop-basic.  However, these are mere conveniences; 
other specifications may define other packages, and there is no 
presumption that an application which supports certain packages is 
automatically 'better' than another that does not."

We can wordsmith more, but you get the idea.

>  I'm really concerned that coming out with profiles here, before there 
> has been an attempt at a more comprehensive modularization and 
> compliance statement, will only tie our hands.  Modularization is not 
> the type of thing that lends itself to a bottom-up approach.  If 
> formulas defines 4 profiles, then metadata defines 3 profiles, and 
> accessibility then defines 6 profiles, we don't end up with just 72 
> profiles.  We end up with chaos.  This needs to be solved top-down.
If there is a more comprehensive effort to create profiles, then they 
can define their own set... or just reuse ours.  No need for chaos.


> That said, we can certainly propose a basic set, or even multiple 
> sets.  In fact we should do this.
Okay!  That's all I'm saying.  Sounds like we're in agreement on what to 
DO... now we're worrying about how to create and present it so that it 
can last into the far future.

>   Again, the concern is prematurely tying our hands before we've fully 
> thought through the ODF-wide ramifications and achieved consensus on a 
> common approach to this common issue.
If we tie the hands of an ODF-wide profiling group, we've done something 
terribly wrong.

I see no reason why an ODF-wide profiling group would HAVE to use the 
same "meta-packages" as we predefine.  So let's make sure the text makes 
clear that specifications can define other packages, too.  I suspect 
that they WOULD use whatever packages we define, for the most part, 
because it's unlikely that a group unfamiliar with spreadsheet formulas 
would do better than we would.   But if they hate the packages we 
predefine, we'll give them the tools to define their own packages and 
make it clear that we're not tying their hands at all.  That way, both 
your concern ("don't tie their hands") and my concern ("need a simple 
way to describe common sets of capabilities") will be met.

--- David A. Wheeler