- From: (unknown charset) Alex Rousskov <rousskov@measurement-factory.com>
- Date: Fri, 18 Oct 2002 10:14:22 -0600 (MDT)
- To: (unknown charset) Dominique Hazaël-Massieux <dom@w3.org>
- cc: (unknown charset) www-qa@w3.org
On 18 Oct 2002, Dominique [ISO-8859-1] Hazaël-Massieux wrote: > As defined in the current TR version of the SpecGL [3], dimensions of > variability are "the ways in which different products that are > conformant to a specification may vary among themselves". > > But in that definitions, do modules really fit as a dimensions of > variability? Yes, if you replace "modules" with "implementation of a subset of modules". Modules are variables in SpecGL context if and only if the spec allows _interoperating_ implementations to implement/use/support different subset of modules. In all other cases, modules are irrelevant to SpecGL. This is, again, a question caused by inaccurate/imprecise definitions used by SpecGL. [ Apologies to everybody on the list who is sick and tired of me pushing for better precision of SpecGL wording ] > So, my question is: do modules really define a relevant dimension of > variability? > I don't think they do, but would like to get others' feedback on this. As they are defined now, modules MAY define a relevant dimension of variability. In other words, some modules are variables, some are not. There is so much variability in the current definitions, that almost everything is possible. > I think however they raise another important issue, which is > interdependencies between specifications (module A needs module B; > profile X include modules Y and Z; Level N is composed of module O > and P) that we ought to address, but I don't think they fit well in > the DoV framework. This is a yet another specific problem that ought to be addressed on a much higher level. Is it bad that A needs B? The answer depends on A, B, and the spec in question. SpecGL should not prohibit or even discourage dependencies. SpecGL should prohibit undocumented dependencies (as a part of a more general "everything that is introduced by the spec, must be defined" checkpoint). If we can define a "good dependency", we should encourage them and discourage bad ones. I do not know how to define a good dependency. Thanks, Alex. -- | HTTP performance - Web Polygraph benchmark www.measurement-factory.com | HTTP compliance+ - Co-Advisor test suite | all of the above - PolyBox appliance
Received on Friday, 18 October 2002 12:14:30 UTC