W3C home > Mailing lists > Public > public-wai-ert-tsdtf@w3.org > February 2009

Re: Database design

From: Christophe Strobbe <christophe.strobbe@esat.kuleuven.be>
Date: Thu, 12 Feb 2009 19:43:40 +0100
Message-Id: <>
To: TSD TF <public-wai-ert-tsdtf@w3.org>

Hi Shadi,

At 17:46 12/02/2009, Shadi Abou-Zahra wrote:

>Hi Christophe,
>Christophe Strobbe wrote:
>>At 13:53 12/02/2009, Shadi Abou-Zahra wrote:
>>>Christophe Strobbe wrote:
>>>>At 21:06 11/02/2009, Shadi Abou-Zahra wrote:
>>>>>Ref: <http://www.w3.org/WAI/ER/tests/WebInterface/Mockups/tables>
>>>>><snip />
>>>>Tests table:
>>>>Does the current design support test samples that reference more 
>>>>than one technique? If the Tech column allows only a single 
>>>>technique ID (as opposed to a list), can the Test ID column be 
>>>>unique? We may need a key that is based on Test ID + Tech ID.
>>>No. The idea is that each test sample maps to exactly one 
>>>technique. Is this not the case?
>>Sometimes a success criterion can be met by a single technique, but 
>>sometimes one needs a combination of techniques.
>>I tried to dig up earlier discussions on this subject and found:
>>(31 October 2006),
>>   which also uses the above rationale, and
>>(30 November 2006),
>>   in a thread about choosing a data model to implement the above 
>> in the TCDL 2.0 schema.
>>I hope I haven't missed anything.
>Yes, a technique can map to several success criteria and a success 
>criteria could be addressed by more than one technique. But this is 
>not the point here. Am I missing something?
>Each *test sample* maps to exactly one *technique*. Correct?

The "expectedResult" contains a pass or fail statement that is based 
on whether the test file(s) pass(es) or fail(s) the success criterion 
identified by the "rule" element. If a combination of techniques is 
required to pass a success criterion, test samples that pass such a 
success criterion will also reference more than one technique.

>>I also seem to remember a comment in a fairly recent telecon in 
>>favour of allowing test samples without techniques documented by the WCAG WG.
>That would be easy to implement within the current DB design.


>>>>Files table:
>>>>I wonder if we really need to test files table in the database. 
>>>>The HTML view of the metadata, which you can currently access by 
>>>>following the link in the Title column 
>>>>(<http://www.w3.org/WAI/ER/tests/WebInterface/>), also has this 
>>>>information, and
>>>>1. the test files are probably rarely useful without the context 
>>>>provided by the metadata (description, purpose, pass/fail, technique/failure)
>>>>2. the XML metadata can specify whether the order of the test 
>>>>files is important or not; this is necessary when the set of test 
>>>>files represent a process with a file for each step in the 
>>>>process. This would be harder to implement in a database (though 
>>>>not impossible).
>>>We do need the files in a database to generate views such as this:
>>>  - <http://www.w3.org/WAI/ER/tests/complete>
>>In this view, too, the test files are "orphaned" without the 
>>context of the metadata. The ordering issue also applies there, but 
>>I overlooked it when we discussed this view.
>We agreed that there are situation where we will have orphaned test 
>files, for example the "tools view":
>  - 
> <http://www.w3.org/WAI/ER/tests/complete.php?sort=id&submit=Sort&view=tools>

True, but tools can't read the prose in "description", "purpose" etc 
anyway. Humans, by contrast, can and should.

><snip />
>>>>Technique table:
>>>>This table should also address the fact that a single technique 
>>>>can be relevant to multiple requirements (usually success criteria).
>>>Good point.
>>>Question: can test samples therefore also apply to several requirements?
>>Well, that was a nasty can of worms in BenToWeb, because that could 
>>create problems when the test suite needed to be migrated to a 
>>newer WCAG 2.0 draft. So we decided to map to success criteria 
>>(this was also reflected in the naming conventions) and not to have 
>>multiple references to the same test files.
>>However, now that WCAG 2.0 is cast in stone, we might decide that 
>>the same test file can be referenced by several metadata files, 
>>i.e. the same test file would be used in more than one test sample 
>>without copying it.
>>However, ... if we decide that test file xyz.html for test sample 
>>a_b_d_001 should be in a certain way and we later find that test 
>>file xyz.html is also used for test sample a_b_d_333 and should be 
>>different, we have a conflict. But that kind of conflict could be 
>>solved by creating a new, different test file zzz.html for test 
>>sample a_b_d_333. What do you think?
>First, I think I answered my own question: if each test sample maps 
>to exactly one technique and each technique could map to more than 
>one requirement, then indeed each test sample could map to more than 
>one requirement too. Correct?

Yes, in theory. And in the database.
However, on 22 January 2008 we resolved to have only one primary rule 
and no other rules per test sample:

This means that if technique 123 maps to e.g. success criteria 1.1.1 
and 1.2.1, we will have two test samples, i.e. one for the 
combination SC 1.1.1 - tech 123 and one for the combination SC 1.2.1 
- tech 123. The former would indirectly map to SC 1.2.1 (through the 
technique) but would not have a pass/fail statement for that SC, and 
the latter would indirectly map to SC 1.1.1 but would not have a 
pass/fail statement for that SC.

>AS to the issue you are pointing out, I think we agreed not to reuse 
>test files (not even the dummy pages for forms etc.).

Yes, that is what we agreed on.

Best regards,


>>>><snip />
>><snip />
>   Shadi
>Shadi Abou-Zahra - http://www.w3.org/People/shadi/ |
>   WAI International Program Office Activity Lead   |
>  W3C Evaluation & Repair Tools Working Group Chair |

Christophe Strobbe
K.U.Leuven - Dept. of Electrical Engineering - SCD
Research Group on Document Architectures
Kasteelpark Arenberg 10 bus 2442
B-3001 Leuven-Heverlee
tel: +32 16 32 85 51
Please don't invite me to LinkedIn, Facebook, Quechup or other 
"social networks". You may have agreed to their "privacy policy", but 
I haven't.

Disclaimer: http://www.kuleuven.be/cwis/email_disclaimer.htm
Received on Thursday, 12 February 2009 18:44:31 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:06:02 UTC