W3C home > Mailing lists > Public > www-qa-wg@w3.org > August 2004

Re: [SpecGL Draft] D. Managing Variability

From: Dominique HazaŽl-Massieux <dom@w3.org>
Date: Thu, 26 Aug 2004 11:16:15 +0200
To: Karl Dubost <karl@w3.org>
Cc: "'www-qa-wg@w3.org'" <www-qa-wg@w3.org>
Message-Id: <1093511774.3057.45.camel@stratustier>
Le jeu 26/08/2004 à 01:15, Lynne Rosenthal a écrit :
> As a general principle, variability complicates interoperability. In
> theory, interoperability is best when there are numerous identical,
> complete, correct implementations. However, in practice, the net
> effect of conformance variability is not necessarily negative in all
> cases, when compared to the alternatives. Different sorts of
> variability have different negative and positive impacts. The
> principal danger is "excessive" variability - variability which goes
> beyond that needed for a positive interoperability trade-off, and
> which unnecessarily complicates the conformance landscape.
> Specification writers need to carefully consider and justify any
> conformance variability allowed, making sure it aligns with project
> requirements, use cases and the technology.

I don't know how much a problem this is, but this paragraph almost
appears as is in spec-variability:
"""

As a general principle, variability complicates interoperability. In
theory, interoperability is best when there are numerous identical,
complete, correct implementations. However, in practice, the net effect
of conformance variability is not necessarily negative in all cases,
when compared to the alternatives. For example profiles ‚ÄĒ subdivisions
of the technology targeted at specific applications communities ‚ÄĒ
introduce variability among implementations. Some will implement Profile
ABC, some will implement Profile XYZ, and the two might not
intercommunicate well if ABC and XYZ are fairly different. However, if
ABC and XYZ are subsets of a large monolithic specification ‚ÄĒ too large
for many implementors to tackle in total -- and if they are well
targeted at actual application sectors, then subdivision by profiles may
actually enhance interoperability.

Different sorts of variability have different negative and positive
impacts. The principal danger is "excessive" variability - variability
which goes beyond that needed for a positive interoperability trade-off,
and which unnecessarily complicates the conformance landscape.
Specification writers need to carefully consider and justify any
conformance variability allowed, do so by reference to the project
requirements and use cases, and explicitly document the choices made.
"""

Also, the concept of variability hasn't really been introduced at this
point on this document, so it might be better to start by introducing
the concept, explaining why it matters and maybe simply direct the
reader to ViS; what about the following paragraph:
"""
<p>Specifications allow some sort of variation between conforming
implementations for different goals, e.g. adaptation to a particular
hardware capacity, possibility to use extensions ; this
<dfn>variability</dfn>, while often wanted to allow a broader usage of
the technology, may have bad consequences on interoperability and needs
to be carefully designed to find the right trade-off.</p>
<p>This section gives advices to help finding this balance; the reader
would also gain to read <cite><a
href="/TR/spec-variability/">Variability in Specifications</a></cite>
[<a href="#VIS">VIS</a>] which goes into more details on the analysis of
this variability.</p>
"""

Dom
-- 
Dominique Haza√ęl-Massieux - http://www.w3.org/People/Dom/
W3C/ERCIM
mailto:dom@w3.org


Received on Thursday, 26 August 2004 09:16:16 GMT

This archive was generated by hypermail 2.2.0 + w3c-0.30 : Thursday, 9 June 2005 12:13:18 GMT