QA Review for Charmod

This is a last call comment from Karl Dubost (karl@w3.org) on
the Character Model for the World Wide Web 1.0
(http://www.w3.org/TR/2002/WD-charmod-20020430/).

Semi-structured version of the comment:

Submitted by: Karl Dubost (karl@w3.org)
Submitted on behalf of (maybe empty): 
Comment type: substantive
Chapter/section the comment applies to: Overall
The comment will be visible to: public
Comment title: QA Review for Charmod
Comment:
Bravo!

I have appreciated the reading of your specification. I want to note also that you have class="req" to markup the testable assertions, and like your document is in XHTML, a simple XSLT will help to define a list of assertions for specifications or for implementations. That's very good. 

My following comments will apply to many points in the spec but I have chosen some to illustrate my wording.

  
* Section Conformance

I found very interesting the section 2 on Conformance and particularly the reminder on the definition of SHOULD. Very good comments. 

I would like to know how you plan to enforce the use of charmod in other specifications by process, pubrules, charters? We are faced to the same question in QA WG. 


* Testable Assertions/Requirements

I found interesting the way you have declared the rules of Conformance for your specifications. I would like to know if there's a plan for a Test Suite or at least Examples and Techniques to demonstrate your technologies.

For example in the first statement (Testable assertion?), I had difficulty to define a binary test case, is it possible to have testable examples for each rule in a separate document. It will help people understand the statement you have defined.

--------
3.1.2 Units of aural rendering
[S] [I] Specifications and software MUST NOT assume that there is a one-to-one correspondence between characters and the sounds of a language.
--------

Here I clearly understand that there's not *necessary* correspondance but it could be sometimes. So it means for me that in the set of all possible values, some will be false, and so invalidate the one to one relationship. 

I don't know if it's better, but you will tell me:

---------
[S] [I] Specifications and software MUST allow the correspondence between one phoneme and mutliple characters when necessary.
---------

Because for me it seems more testable and comprehensive for a developper or a specification editor.

As a general rule, even if it seems valid, avoid the use of MUST NOT when it's possible to define a MUST.


-----------
3.1.3 Units of visual rendering
[S] Protocols, data formats and APIs MUST store, interchange or process text data in logical order.
------------

Why only S (Specifications) ? Do you mean:

-> [S] (Specifications of?) Protocols, data formats and APIs MUST store, interchange or process text data in logical order.
or 
-> [I] Protocols, data formats and APIs MUST store, interchange or process text data in logical order.

+ Ambiguous definition, can you clarify? What's the meaning of "be clear" in this context. The answer will depend on the people.

---------------
3.1.7 Summary
[S] When specifications use the term 'character' it MUST be clear which of the possible meanings they intend. 
---------------

Do you mean? 

-> [S] When specifications use the term 'character', the specifications MUST define the possible meanings they intend. 


When you have multiple rules, please make it a list to be more readable.



For the QA WG.

Thank you for this specification.

--
Karl Dubost
Conformance Manager
http://www.w3.org/QA/



Structured version of  the comment:

<lc-comment
  visibility="public" status="pending"
  decision="pending" impact="substantive">
  <originator email="karl@w3.org" represents="-"
      >Karl Dubost</originator>
  <charmod-section 
    ></charmod-section>
  <title>QA Review for Charmod</title>
  <description>
    <comment>
      <dated-link date="2002-06-19"
        >QA Review for Charmod</dated-link>
      <para>Bravo!

I have appreciated the reading of your specification. I want to note also that you have class="req" to markup the testable assertions, and like your document is in XHTML, a simple XSLT will help to define a list of assertions for specifications or for implementations. That's very good. 

My following comments will apply to many points in the spec but I have chosen some to illustrate my wording.

  
* Section Conformance

I found very interesting the section 2 on Conformance and particularly the reminder on the definition of SHOULD. Very good comments. 

I would like to know how you plan to enforce the use of charmod in other specifications by process, pubrules, charters? We are faced to the same question in QA WG. 


* Testable Assertions/Requirements

I found interesting the way you have declared the rules of Conformance for your specifications. I would like to know if there's a plan for a Test Suite or at least Examples and Techniques to demonstrate your technologies.

For example in the first statement (Testable assertion?), I had difficulty to define a binary test case, is it possible to have testable examples for each rule in a separate document. It will help people understand the statement you have defined.

--------
3.1.2 Units of aural rendering
[S] [I] Specifications and software MUST NOT assume that there is a one-to-one correspondence between characters and the sounds of a language.
--------

Here I clearly understand that there's not *necessary* correspondance but it could be sometimes. So it means for me that in the set of all possible values, some will be false, and so invalidate the one to one relationship. 

I don't know if it's better, but you will tell me:

---------
[S] [I] Specifications and software MUST allow the correspondence between one phoneme and mutliple characters when necessary.
---------

Because for me it seems more testable and comprehensive for a developper or a specification editor.

As a general rule, even if it seems valid, avoid the use of MUST NOT when it's possible to define a MUST.


-----------
3.1.3 Units of visual rendering
[S] Protocols, data formats and APIs MUST store, interchange or process text data in logical order.
------------

Why only S (Specifications) ? Do you mean:

-> [S] (Specifications of?) Protocols, data formats and APIs MUST store, interchange or process text data in logical order.
or 
-> [I] Protocols, data formats and APIs MUST store, interchange or process text data in logical order.

+ Ambiguous definition, can you clarify? What's the meaning of "be clear" in this context. The answer will depend on the people.

---------------
3.1.7 Summary
[S] When specifications use the term 'character' it MUST be clear which of the possible meanings they intend. 
---------------

Do you mean? 

-> [S] When specifications use the term 'character', the specifications MUST define the possible meanings they intend. 


When you have multiple rules, please make it a list to be more readable.



For the QA WG.

Thank you for this specification.

--
Karl Dubost
Conformance Manager
http://www.w3.org/QA/
</para>
    </comment>
  </description>
</lc-comment>

Received on Tuesday, 18 June 2002 20:38:11 UTC