W3C home > Mailing lists > Public > www-qa@w3.org > October 2002

(unknown charset) Re: Are modules really a DoV? and levels/profiles?

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
Message-ID: <Pine.BSF.4.44.0210180946230.27371-100000@measurement-factory.com>

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.



                            | 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

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:40:29 UTC