Re: Review QA Framework: Specification Guidelines

> 
> 2.5  All XML Activity WGs have been asked to review
>   QA Framework: Specification Guidelines 
>   http://www.w3.org/TR/2004/WD-qaframe-spec-20041122/
> whose Last Call Ends 28 January 2005.
> 
> ACTION to Dmitry:  Review QA Framework: Specification Guidelines
> and report back to the XML Core WG by January 18th.
> 

I reviewed the document. It is readable and might be useful to somebody
who have never written specs, in particular specs that define conformance
requirements. While I have some conceptual and structural concerns in
regard to this spec, I do not think they are of any importance to
Core WG. The only normative part of the spec is a set of requirements
that I include below. The most of them are fine. However, I do not like
2 requirements, 2.2.A and 4.4.B, to be normative. It might be a time
consuming and nor very useful task to identify a set of products, or
technologies, targeted by a particular XML standard or affected by a
change in such standard. For these 2 requirements I've included their
explanations from the document.

------------------------------------------------------------------------------

1.1 Requirement A: Include a conformance clause.
2.1 Requirement A: Define the scope.

2.2 Requirement A: Identify who or what will implement the specification.
  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. 

2.3 Requirement A: Make a list of normative references.
3.1 Requirement A: Define the terms used in the normative parts of the specification.
3.1 Requirement B: Create conformance labels for each part of the conformance model.
3.2 Requirement A: Use a consistent style for conformance requirements and explain how to
     distinguish them.
3.2 Requirement B: Indicate which conformance requirements are mandatory, which are
      recommended and which are optional.
4.1 Requirement B: If the technology is subdivided, then indicate which subdivisions are
     mandatory for conformance.
4.1 Requirement C: If the technology is subdivided, then address subdivision constraints.
4.3 Requirement A: Address Extensibility.
4.4 Requirement A: Identify deprecated features.

4.4 Requirement B: Define how deprecated feature is handled by each class of product.
  By deprecating a feature, the Working Group indicates its desire that the feature disappear
  from a future version of the specification. The motivation may be to convert an old feature to
  a newer one or to remove an old, dangerous, redundant or undesirable feature. Regardless
  of the reason, it is important to define the affect this has on implementations that may
  encounter this feature (e.g., consumer products such as user agents or producer
  products such as authoring tools). Will use of the deprecated feature be tolerated?
  Will it signal an error or a warning? Typically, it is expected that a deprecated feature
  would not affect a consumer (e.g. user agent), while a producer (e.g. authoring tool) should
  issue a warning.

Received on Wednesday, 19 January 2005 05:46:47 UTC