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

Re: modularity in specifications

From: David Marston/Cambridge/IBM <david_marston@us.ibm.com>
Date: Wed, 10 Apr 2002 16:13:01 -0400
To: www-qa-wg@w3.org
Message-ID: <OF41781765.A1050393-ON85256B97.006B9621@lotus.com>

Lynne Rosenthal started a thread about "conformance" means when there
are several Recommendations involved. Later, Andrew Thackrah applied
the dilemma to our nascent Spec Guidelines. In particular, he opined:
>Classification is products is an open-ended task.
>This places an obligation on spec maintainers to update the spec for
>each new product class....
>Classifying products is a commercially sensititive issue...

I don't think the situation is that worrisome. I refer back to my
position paper at the Workshop (or, I would if the link worked). We
can classify the static or dynamic entities being defined by the
Recommendations, then generically describe the "product classes"
that are affected.

I. Content/data (e.g., MathML, SVG)
   A. Tools that create or edit it
   B. User Agents that [dis]play it
   C. Other modules that consume it??
II. Protocols (e.g., SOAP)
   A. Agents that transmit it
   B. Agents that receive it
III. Processors (e.g., XSLT, XML Query)
   A. The processor itself
   B. Tools that create the source document
   C. Other modules that encompass the processor??
   D. Modules that consume the output??
IV. APIs (e.g., DOM)
   A. Modules that implement the API
   B. Modules that consume the output??
V. Notation/syntax (e.g., XPath)
   A. Tools that create or edit it
   B. Other specs that encompass it
The above list can be rigorized, but you get the idea. If a WG is
producing a Recommendation of a particular nature (I-V), then they
MUST define "conformance" for each product class (A-D) that does
not have question marks above, and must (not capitalized), in their
internal deliberations, determine whether they impose some sense of
conformance onto products in the other classes.

Lynne also raised some questions about a specification that "is
dependent on other specifications" and/or a specification that
specifies behavior of a product-class that will be dependent on
other modules defined by other specifications. XPath is a great
example here: one could produce an XPath evaluator as a module
unto itself, but the XPath Rec doesn't acknowledge such a
possibility. The specs that rely on XPath (XSLT, XML Query,
XPointer) implement spec-to-spec dependency rather than
spec-to-module dependency. There should be some sort of spec
guideline for such situations, and probably a coordination
requirement as well. By "coordination requirement", I mean that
the WG issuing the Rec depended upon (e.g., XPath) has some
obligations to all the WGs that depend on it. In our example, the
XPath Rec should not be expanded to specify an "XPath evaluator
module" without notification to various interested parties.

I think coordination within the W3C can be improved by using a
taxonomy of Recommendation types similar to the I-V list above.
.................David Marston
Received on Wednesday, 10 April 2002 16:16:21 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:14:26 UTC