Re: Interrelationships between dimensions of variability (long)

Dominique Hazaël-Massieux wrote:
>I'm in the process of evaluating the work needed to write the new
>chapter about the concepts used in the QA specification guidelines.
>One of the section of this chapter is supposed to be a generic
>approach on the relationships between dimensions of Variability.

Below are my observations, mostly in the abstract, about the interactions
that can be expected between different Dimensions of Variablity (DoV).
The DoV are arranged in this order because the first dimension has the
most "degrees of freedom" and is most likely to control the variability of
subsequent dimensions, and so on down a progression of dependencies.

CLASS OF PRODUCT is the most independent of the DoV. Products in one class
would be expected to interoperate in the sense of being substitutable.
(Example: all XSLT processors would fill the same role and could be
considered interchangeable.) Products in different classes might
interoperate in the sense of exchanging compatible I/O. Either way, an
implementation may have to negotiate with other software about 
capabilities
beyond the required minimum. Products in different classes would have
entirely different profiles, modules, discretionary choices, and
extensions.

Where a WG has defined two classes of product and an intended relationship
between the two, then they should review the respective minimum
requirements, levels, and deprecated items of each class to ensure that
they are compatible with the intended relationship. (Dom: I'd suggest that
this be the basis of a cautionary note in 3 cells of the matrix.)

CONFORMANCE POLICY, specifically MINIMUM REQUIREMENTS would be dependent
on the class of product, but would affect the requirements of each profile
and be part of the lowest level. Regarding modules, there could be a
minimum requirement that at least one of a set of modules be implemented.
Minimum requirements could conceivably impose some constraints on
discretionary items, and F&O (now in LCWD) provides a good example: no
particular collations are required, but any implementation must be able to
collate. Regarding extensions, I would point out that some WGs might 
impose
a conformance policy regarding correct processing in non-extended
situations, perhaps even with a mandated mode that ignores all extensions.
The basic conformance policy probably sets the foundation for the
deprecation policy, for versions after 1.0, of course.

(Dom: There are definite matrix entries for minimum vs. levels, vs.
discretionary, and vs. extensions.)

PROFILES may be constructed out of modules and/or levels, or drive some
discretionary choices. Since a profile is a bundle of capabilities 
designed
to address the needs of something external, such as a class of hardware or
a vertical industry segment, it is even possible that a profile could
require a particular behavior regarding deprecated content. Sometimes it
seems that "modules can have profiles" but the examples I've heard really
transform into "modules can have levels, which might be specified so as to
meet the needs of certain profiles", so a profile drives the modules 
rather
than the other way. A profile for hardware with weak capabilities could
mandate that there be no extensions.

(Dom: This means there are matrix entries for profiles vs. everything 
other
than minimum requirements.)

MODULES could have more than one level. For example, an audio module might
have levels 1 to 4 defined, while a video module has levels 1 to 8, each
higher level representing higher fidelity of the respective material. In
this example, the levels aren't a threat to interoperability if they will
only affect humans. Modules could be used for dealing with deprecated
features, especially if the WG wants to allow a couple alternative means
(discretionary choice!) of doing so. If modules have features confined to
the scope of just a module, those features might conceivably be 
extendable.

(Dom: This means there are matrix entries for modules vs. everything, some
having been pointed out earlier.)

LEVELS would be used in a negotiation with other software, so that the 
lower
level would be chosen by both parties if the two differ in the level
implemented. A higher level might constrain certain discretionary items,
such as requiring certain character sets or collation routines be 
available.
If there are several features between Level n and Level n+1, an
implementation may conform at Level n and implement some of the n+1 
features
as "extensions" (if the spec allows it), provided that it only claims 
Level
n conformance. It's possible that a low-level implementation might not
support deprecated content for reasons of speed or small footprint.

(Dom: This means there are matrix entries for levels vs. everything, some
having been pointed out earlier.)

DEPRECATION presents some interesting considerations, especially for a 
spec
that defines more than one class of product. Old-style content or behavior
may force the creation of discretionary choices (to warn or not), even if
the old style must be accepted. All the DoV above this one should set
expectations for support of deprecated features as they see fit. WGs 
should
be cautious about tying such support to particular levels, unless they
think that a whole level could be deprecated someday. Similarly, if the WG
thought that the minimum requirements could be raised in a later version,
then some features could move from deprecated to obsolete when
implementations of the newer version had become sufficiently ubiquitous.
Deprecation affects extensions as follows: a feature not defined for 
version
n may be provided as extensions in several implementations, then version 
n+1
defines a sanctioned version of the feature, but not in a clean-slate form
due to popularity of certain details of the old extensions, then version 
n+2
forces the clean-slate design. Let's hope *that* doesn't happen too often.

(Dom: This means there are matrix entries for deprecation vs. everything,
except possibly minimum requirements.)

DISCRETIONARY ITEMS present small design choices to the implementer and 
are
often contingent on larger design choices. For example, a discretionary
choice may be applicable only when an implementation includes a particular
module, or maybe only when it doesn't. The choice of whether to implement 
a
module is not lumped in with discretionary items because a module is a
substantial bit of functionality while discretionary items (as addressed 
in
SpecGL) are about locales, warnings, and similar integration facilitators.

Discretionary items should arise in the spec only as a consequence of a
WG's reluctance to force worldwide uniformity faster than people are ready
for it, or to tolerate differences in human behavior (e.g., natural
language) that are never expected to become uniform.

(Dom: The matrix entries for discretionary vs. other DoV have been noted
above.)

EXTENSIONS should be strictly beyond a WG's work. If a particular class of
product, profile, discretionary item, etc. were to require an extension, 
the
WG should think harder about addressing the feature in the spec. Once
extensions are cleared as entirely optional, we would expect that the WG
requires any extensions to be completely dependent on (i.e., subservient 
to)
all the above DoV; an extension cannot "break" any modules or levels, 
cannot
implement a discretionary item contrary to the constraints on that item, 
etc.

(Dom: The matrix entries for extensions vs. other DoV have been noted 
above.)

SPEC VERSION is not a DoV for SpecGL (which states guidelines for one
version), but it could affect the above DoV. Most obviously affected is
deprecation, since you don't even have any deprecation issues until there 
is
more than one spec version. If the spec has profiles based on hardware, 
newer
versions could address improvements in the hardware, or even whole new
classes of hardware. A newer version could add new levels, and expand or
reduce discretionary items (reduce if the marketplace made it clear that 
all
implementations had to make the same choice to be competitive). As 
previously
noted, a new version could add features which had been delivered as
extensions in the past. It could also define new modules (e.g., schema
awareness, namespace awareness) or raise the minimum requirements.
.................David Marston

Received on Sunday, 8 June 2003 22:10:29 UTC