Where "Rules for Profiles" fit into Spec Guidelines

The QAWG asked me, as the enumerator of the Seven Types of W3C Specs
(seen in Guideline 2 of the Spec Guidelines), to address classification
of a spec that provides Rules for Profiles. A spec may define some
profiles, as anticipated in Guideline 3, or it may provide some rules
to be used by others when creating profiles, or it may do both.

GL 3 requires that a spec make a clear and findable statement about
whether profiles are used, and related statements about how they are
used in conformance claims and assessment of conformance. If other
dimensions of variability are in use as well, most will probably
apply per-profile, depending on public reaction to the whole
scheme of variability. It's worth noting that GL 3 doesn't impose
many constraints on individual profiles. In particular, the only way
in which pre-defined profiles may differ from those derived from
rules, and that is recognized in GL 3, is if a "full" or "tiniest"
profile exists, it would have to be a pre-defined one.

Derivation of profiles from a set of rules is an activity that would
happen after a spec is finalized (achieved Rec status). Thus, the set
of rules is as much a specified item (target of the spec) as other
items on the lists in GL 2. I propose that the List of Seven spec
types be expanded to eight, viz.,
1. foundation or abstract (e.g., Infoset),
2. content/data (e.g., MathML, SVG),
3. protocols (e.g., SOAP),
4. processors (e.g., XSLT, XML Query),
5. APIs (e.g., DOM),
6. notation/syntax (e.g., XPath),
7. set of events (e.g., one part of XForms),
8. rules for deriving profiles (e.g., part of SVG).

Do the profiles so derived exemplify a Class of Product? Probably. The
profile can be an additional set of content-objects, functions, or
events beyond the basic ones, for use in a specific application or
field of endeavor. The profile mechanism might also be used to set
a contract between software and hardware, such as defining a set of
expectations for a PDA as a profile of a spec first written assuming
full-power workstations. For the next draft of the SpecGL, I think
there should be a new bullet item on the un-numbered list of classes
of product in GL 2, saying:
profile (see GL 3) derived from the spec's Rules for Profiles

Finally, it's probably worth adding a new Checkpoint 3.6 that says:
3.6 If the spec allows other groups to define new profiles in the
future, provide rules for derived profiles that will enable the
derived profiles to be well-specified.
Derived profiles should specified in a way that meets all the
pertinent checkpoints of this document. Derived profiles should not
clash with pre-defined profiles, if there are any. Checkpoints from
Guideline 9 (extensions) can be adapted into rules for profiles.
The rules must be testable, so that an independent tester can
determine whether the specification of a derived profile conforms
to the rules for derived profiles in the base specification.

I hope the above changes will clarify the difference between
pre-defined profiles and rules for profiles, both of which may
appear in a W3C Rec being written per the SpecGL constraints.
.................David Marston

Received on Sunday, 11 August 2002 23:28:48 UTC