W3C home > Mailing lists > Public > www-qa@w3.org > April 2004

Re: Testability again (was: [QA Review] CharMod for the Web 1.0: Fundamentals WD 25 Feb 2004)

From: Al Gilman <Alfred.S.Gilman@IEEE.org>
Date: Tue, 13 Apr 2004 12:43:52 -0400
Message-Id: <p06020433bca1b68a26a4@[10.0.1.2]>
To: www-qa@w3.org, w3c-i18n-ig@w3.org

At 1:09 PM +0900 4/13/04, Martin Duerst wrote:
>[I have added the I18N IG to this discussion.]
>
>At 00:11 04/04/12 +0200, Bjoern Hoehrmann wrote:
>
>>* Karl Dubost wrote:
>>>This is a review of
>>
>>>http://www.w3.org/TR/2004/WD-charmod-20040225
>>
>>>C001   [S]   [I]   [C]   Specifications,  software and content MUST NOT
>>>assume that there is a one-to-one  correspondence between characters
>>>and the sounds of a  language.
>>>
>>>===> How do you test that for each implementations [S][I][C]? What will
>>>be the three tests that you will be able to create to demonstrate the
>>>implementability of this during the CR period where you will seek for
>>>implementation? If you can't design a test for it, it means that your
>>>assertion is not testable, therefore not implementable.
>>
>>I am confused. How is a "test" relevant in this regard? You would test
>>a specification by reading it which would not involve the creation of
>>tests. Maybe you could point at the tests the QA WG created for SpecGL
>>to give an idea how to design such tests for Charmod? It also seems that
>>in order to create a test for software or content one would need an
>>interface to these things, an API or a specific document format, none of
>>which is defined in Charmod and hence cannot be directly tested through
>>Charmod. My understanding is rather that specifications that require
>>Charmod conformance are responsible to demonstrate interoperability. You
>>would not create standalong charmod conforming software or content.
>
>Usually, yes. But one can imagine implementations or
>content that don't have a spec, but still conform.
>
>>I also wonder what the QA WG means by "testable", my LC comment
>>
>>   http://www.w3.org/QA/WG/2004/02/cr-issues.html#x30
>>
>>still appears to be unresolved. This makes communication quite
>>difficult, I can hardly argue with you whether certain things are
>>testable if we disagree about the definition of "testable".
>>
>>Based on your comments I would say that I strongly disagree with your
>>definition. As far as I am concerned, human inspection of a spec makes
>>it possible to determine with complete reliability (!) whether the spec
>>adheres to Charmod or not (minor issues aside). Much like with SpecGL.
>>So, what am I missing here?
>
>According to a discussion I had with Karl last week, this is not
>his issue. It is much more with the word 'assume'.
>
>>  > I think one of
>>>the problems comes from the "assume".
>>>        Imagine a language where you have "a one-to-one 
>>>correspondence between
>>>characters and the sounds of a  language". If the software implements
>>>only this language because it's a specific use for only this language.
>>>It means that it's not conformant to C001, even if this software does
>>>the correct thing.
>>
>>No, you cannot know and assume the same thing at the same time. If you
>>know that the only language you implement has this characteristic then
>>you do not assume this characteristic and are thus conformant.
>
>This is an interesting way to explain things. What I told Karl
>was that we would be perfectly happy if a software written for
>only one specific language would not be conformant with Charmod.
>The WWW, and Charmod, are in essence multilingual.
>
>In our discussion, my understanding was that Karl didn't like
>the word 'assume' because it's too vague.

I prefer Bjorn's reading of this one. There are software and content
instances which properly process characters as constructors of a
phonetic script. IPA is a classic example. We should not write the
Character Model in a way which defines these as in violation of the
model. They should be regarded as processing under an extension of
the model.

The point to be made here is not that applications may not use
characters as a phonetic script, but that the *Character Model
Established Here* does not bind phonetic semantics to the characters,
and that applications *using the characters with phonetic semantics*
must formally introduce those semantics above and beyond reliance on
the Character Model set forth here.

Rather than the "must not assume" language, say "this specification
does not assign or recognize phonetic semantics for charaters (and
such semantics is not correctly bindable in the generality of this
language-independent plane of definition). Applications wishing the
characters they employ from this model to denote phonetic semantics
must separately define the phonetic semantics intended. No phonetic
interpretation is defined here for them to inherit."

Note that the practical state of W3C technology is represented by SSML where
customary vocalization of character-denoted language is left to the knowledge
implicit in the coding of the TTS engine.

A[informative] note referring to the relevant provisions in VoiceXML 
(as SSML is still in CR)
might help here.

>>  >*KD-004
>>>C008   [S]   [I]   Specifications and implementations of sorting and
>>>searching algorithms SHOULD accommodate all characters in Unicode.
>>>
>>>===> What's happening if you implement all western languages but not
>>>asian because the context of applications do not make it necessary. Do
>>>I still have to implement everything? If not how can I be conformant?
>>
>>If you have fully understood and carefully weighted the implications of
>>the deviation, you may deviate. This is covered by RFC 2119 which is
>>properly referenced on Charmod.
>
>The 'SHOULD' here provides an escape hatch, but I don't think
>that this is the important part of C008 with respect to Karl's
>comment. A software may do high-quality sorting of only the Latin
>characters, and sort the rest just e.g. by Unicode code point.
>What it may not do is to blow up when getting a non-Latin
>character.
>
>Regards,     Martin.
Received on Tuesday, 13 April 2004 12:44:33 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:40:35 UTC