Re: Database design

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.

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

Technique table:

This table should also address the fact that a single technique can 
be relevant to multiple requirements (usually success criteria).

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

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

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" 

Requirement table:
No comment. (Except that Principles currently don't have 
Understanding docs or techniques/failures.)

StrReview, CntReview, Ballot, Decision, decValue:
No comment.

Best regards,


>   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 10:57:48 UTC