[SpecGL Draft] B2 What must conform

Revised Version.  Added more examples, Technique, etc.  (most of the 
examples taken from old SpecGL and its Tech-Example document)

What needs to conform?

Principle: Identify who or what will implement the specification

What does this mean?
Clearly identify the class of products (i.e., type of products or services) 
to which the specification applies.  If multiple classes of products are 
targeted by the specification, make sure each are described.   Examples of 
classes of products include: content, producer of content, player, 
protocol, API, agent, guidelines.

Why care?
It helps define the scope of the specification and is needed when defining 
conformance.  It also helps the reader know what is being targeted by the 
specification – that is, to discover and focus on what they have turned to 
the document for and avoid what they may find immaterial.

Think about all the types of products or services that will implement this 
technology, group those that are similar and/or basically achieve the same 
purpose, and determine the generic name for the group.  This would be the 
class of product.
List the classes of products that will implement the specification.
Describe them somewhere at the beginning of the specification.


QA Framework: Specification Guidelines defines one class of product – 

<http://www.w3.org/TR/smil20/smil20-profile.html>SMIL 2.0 Language Profile 
chapter 13), there are 2 classes of products: documents and basic user agents.

<http://www.w3.org/TR/MathML2/>Mathematical Markup Language (MathML) 2.0 
there are output-compliant, authoring tools and input-compliant, 
rendering/reading tools.

         Ruby. The conformance section of Ruby is very explicit and 
detailed about classes of product. For each of these classes, 
<http://www.w3.org/TR/ruby/#conformance>Ruby conformance section defines a 
set of rules, the implementers or the users must respect. It defines rules 
for markup, dtd, document, module, generator, interpreter.

         XHTML Modularization. The 
Definition of this specification introduces also classes of product and 
defines the conformance for each of these classes.

         <http://www.w3.org/TR/2001/REC-xmlschema-1-20010502/>Schema Part 
1 could be said to define an abstract notion of "schema validity" but this 
checkpoint can only be satisfied if the Recommendation says explicitly 
whether it is setting expectations of an XML parser or of a "schema 
validator" that could be stand-alone.

<http://www.w3.org/TR/2001/REC-xmlschema-2-20010502/>Schema Part 2 defines 
data types, so it is a specification of type 2 above  content/data  and 
it is used as a foundation by other specifications (e.g., XPath 2.0) as 
well as being part of the schema validator and hence parser requirements. 
The specification could define the behavior of a data-input tool that 
rejects data not fitting the schema, but it probably would not because the 
tool would be expected to use a parser module to validate the data. To 
satisfy this checkpoint, the Schema Part 2 specification has to make clear 
whether it is to be taken as an independent specification of a parser (that 
produces data from arbitrary strings) or a foundation to be used by other 

Received on Friday, 20 August 2004 12:34:50 UTC