Re: Database design

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>
>>>>
>>>> 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:
> * 
> <http://lists.w3.org/Archives/Public/public-wai-ert-tsdtf/2006Oct/0072.html> 
> (31 October 2006),
>   which also uses the above rationale, and
> * 
> <http://lists.w3.org/Archives/Public/public-wai-ert-tsdtf/2006Nov/0047.html> 
> (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?


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

We agreed that presenting the full metadata is the optimal format for 
tools but that many will not support that formal for a while.


> I should have mentioned that the order of the test files is relevant if 
> the sequential attribute in TCDL has the value "true": 
> <http://bentoweb.org/refs/TCDL2.0.html#edef-files>.
> 
> 
>> However, I did not think of the order of the files. I will look at that.

Will look at how to do an order.


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

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


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

OK, please let me know.


>>> 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" 
>>> (<http://bentoweb.org/refs/TCDL2.0.html#adef-expectedresult>).
>>
>> 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).
> 
> OK.

Thanks,
   Shadi

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

Received on Thursday, 12 February 2009 16:46:42 UTC