Re: Database design

Hi Shadi,

At 13:53 12/02/2009, Shadi Abou-Zahra wrote:
>Hi Christophe,
>Christophe Strobbe wrote:
>>Hi Shadi,
>>At 21:06 11/02/2009, Shadi Abou-Zahra wrote:
>>>Ref: <>
>>>Please find an outline of the database I plan to implement for the 
>>>test samples. Feedback is welcome!
>>>Especially the techniques, technologies, and features mappings is 
>>>quite tricky. We have n:n relationships which is never a good sign...
>>Thanks for your work on the DB design. Below are a few comments. It 
>>is possible that you have addressed them somehow, but it's 
>>important to have this in an unambiguous and explicit form.
>>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.

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.

>>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 
>>(<>), 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:
>  - <>

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.

I should have mentioned that the order of the test files is relevant 
if the sequential attribute in TCDL has the value "true": 

>However, I did not think of the order of the files. I will look at that.
>>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?

>>Technologies table:
>>A single test sample often relies on more than one technology: 
>>XHTML + CSS, XHTML + JavaScript, XHTML + CSS + JavaScript. Would 
>>this table treat HTML 4.01 and XHTML 1.0 as different technologies? 
>>Would it treat XHTML 1.0 and XHTML 1.0 as different technologies? 
>>(The current metadata do this by using different URLs. The 
>>disctinction between XHTML 1.0 and XHTML 1.1 is relevant for 
>>techniques that use Ruby Annotation to address SC 3.1.6 (Pronunciation).)
>Yes, the thought is that each of CSS, HTML 4.01, XHTML 1.0, XHTML 
>1.1 is a separate technology (stored in the "Technology" table). A 
>test sample can have any number of technologies (mapped through the 
>"Technologies" table). The database does not consider technology 
>families such as XHTML or such. Each technology (identified by its 
>URI) is distinct.

OK. Thanks for the clarification.

>>Features table:
>>No comments. (This table treats e.g. element INS in HTML 4.01 as a 
>>different feature from INS in XHTML 1.0, just like our XML 
>>metadata, because each technology feature has a URL.)
>I had a tough time with this one. Note that there is no relationship 
>between the features and the technologies in this database. It 
>merely lists the features that belong to a test sample. I'd like to 
>improve this (to facilitate the search functionality).

This is tricky. I need more time to think about this.

>>Technology table:
>>No comment.
>>Feature table:
>>No comment.
>>Status table:
>>No comment.
>>Result table:
>>Strictly speaking, TCDL 2.0's expectedResult attribute also allows 
>>the value "cannotTell" 
>Yes, I had that in and dropped it again. Not sure why (cannot tell, 
>ha ha). I'll put it back in.

OK. pass ;-)

>>Requirement table:
>>No comment. (Except that Principles currently don't have 
>>Understanding docs or techniques/failures.)
>Yes, I might drop the Principles given this context (see the 
>separate thread on rulesets.xml).


Best regards,


>>StrReview, CntReview, Ballot, Decision, decValue:
>>No comment.
>   Shadi
>Shadi Abou-Zahra - |
>   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.


Received on Thursday, 12 February 2009 15:55:13 UTC