Re: QA Review for Charmod

Hello Karl,

Many thanks for your comments. Just a few notes from myself:

At 09:38 02/06/19 +0900, Karl Dubost wrote:

>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

Why didn't you submit the comments one-by-one with the form?
Did you think it was too difficult? Was it not clear that
that's what should be done? Did you just want to save time,
because you already had all the text typed up?
[I ask because the form is an experiment, and any feedback
is appreciated.]


>The comment will be visible to: public
>Comment title: QA Review for Charmod
>Comment:
>Bravo!

Thanks!


>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.

Actually, the source is in XML, so XSLT can be applied to XML directly :-).


>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?),

Which one?


>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.

Binary tests are very difficult in many case, or have to be worked
out individually for each spec (e.g. XML, CSS,...)


>--------
>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.
>---------

This would be wrong because there are also multiple phonemes - one character
and multiple phonemes - multiple characters. Excluding the one-to-one case
looked easier.


>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.

I think it can be [S/I/C]. Specifications don't store or interchange
data, but they specify how it's done.



>---------------
>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.

Yes. But 'possible meanings' -> 'meaning'.


>When you have multiple rules, please make it a list to be more readable.
>
>
>
>For the QA WG.
>
>Thank you for this specification.

Thanks for the comments.     Regards,    Martin.

Received on Thursday, 20 June 2002 05:22:40 UTC