- From: Lynne Rosenthal <lynne.rosenthal@nist.gov>
- Date: Fri, 20 Aug 2004 08:34:48 -0400
- To: www-qa-wg@w3.org, "Karl Dubost" <karl@w3.org>
- Message-Id: <6.0.0.22.2.20040820083317.01c9fcc0@wsxg03.nist.gov>
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. Techniques. 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. Examples; QA Framework: Specification Guidelines defines one class of product – specifications <http://www.w3.org/TR/smil20/smil20-profile.html>SMIL 2.0 Language Profile ([<http://www.w3.org/TR/2003/CR-qaframe-spec-20031110/references#SMIL20>SMIL20], 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 [<http://www.w3.org/TR/2003/CR-qaframe-spec-20031110/references#MATHML20>MATHML20] 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 <http://www.w3.org/TR/2001/REC-xhtml-modularization-20010410/conformance.html#s_conform>Conformance 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 specifications.
Received on Friday, 20 August 2004 12:34:50 UTC