More rigor on product classes

This is a revision of some ideas I sent on 10 April. This gives
additional motivational force for Spec Guideline 3.

Classify the specs and you then have the basis for classifying the
software that may be affected by the spec. Below, we proceed from the
most abstract toward, but not all the way to, the specific of individual
products that could be tested. Andrew take note: we don't have to place
a product into a particular product class.

LAYER 1: Nature of the spec
All W3C "substantive" Recommendations that are intended to affect the
design of software should be classified by what they specify.
0. Foundation/abstract only (e.g., InfoSet)
I. Content/data (e.g., MathML, SVG)
II. Protocols (e.g., SOAP) - describe a dialog or interaction between
    an initiator (often a client) and a responder (often a server)
III. Processors (e.g., XSLT, XML Query)
IV. APIs (e.g., DOM)
V. Notation/syntax (e.g., XPath)
VI. Set of events (XForms has a set)
One Rec could potentially specify more than one of the above, in which
case take the union for all following layers.

LAYER 2: Producers and consumers
The WG should identify which producers and consumers are the targets of
the Rec. This is very clear for a protocol-type spec: the two parties
to the dialog are the targets. For a processor-type spec, the
processor is the consumer of an XML vocabulary defined in the spec.
For content-type specs, there may be one or more consumers that take
the content and "play" it in some way. The WG should take care to
consider intended pipelines connecting their target with modules
defined in other specs.

LAYER 3: Product classes
Even the most elaborate Integrated Development Environment can be
portrayed in a simplified way in a scheme of product classes, because
at this layer, we want to define the role(s) of the product with
respect to what the Rec defines. If a product produces the content that
is the target of a content-type spec, we don't care whether it's an
"editor" or "generator" or whatever. But the Rec, in implementing
Guideline 3, should define terms for the product classes affected.
Here is a menu to start:
A. Producer of content (may divide into initiators and modifiers)
B. Player (read-only consumer, conveys content in non-XML way)
C. Consumer in a one-way pipeline
D. Server/responding agent/implementer of API (consumer & producer)
E. Processor (consumer of its vocabulary/instructions)
F. Module that hosts the processor
G. Producer of instructions/commands to processor
One Rec could define more than one player. For example, MathML
could address the behavior of display of math notation and also a
consumer that parses the MathML as a formula and uses it for
mathematical processing.

LAYER 4: Product capability
This layer should mainly be used for profiles. Here, the WG defines
characteristics of the product that impose *practical* constraints on
its ability to produce or consume. Standard examples are low-res
displays, low-bandwidth or slow communication, limited input
expressiveness (e.g., TouchTone keypad), and so forth.

From the above, we can now say that checkpoint 3.2 means that the
Rec goes role-by-role (from layer 3 above), possibly profiled as
described in layer 4, and states the requirements that it imposes on
any product that would claim to fulfill that role.
.................David Marston

Received on Thursday, 18 April 2002 23:08:15 UTC