[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [office-formula] Goals/levels/packaging/complex numbers
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]