Re: Linking 'location' and 'technique': models and examples

Hi,

Thanks for this summary and the opportunity to comment. I strongly 
prefer option B, can live with option C, and dislike option A.

Regards,
   Shadi


cstrobbe wrote:
> Hi,
> 
> I had an action item to provide examples of two ways to link a 
> 'location' with one or more 'technique' elements. This issue has been 
> discussed a few times before [1] [2], and there was another discussion 
> on the last conference call. We did not reach consensus, so here's a 
> description of the three models that were discussed.
> (Note that we need to allow references to more than one technique for 
> some success criteria [3], so the first proposal in [1] is not 
> appropriate.)
> 
> 
> Model A: using ID and IDREFS
> 
> Keep the sequence 'locations' (containing one or more instances of 
> 'location') and 'techniques' (containing one or more instances if 
> 'technique') as in the current schema, but link them by means of ID and 
> IDREFS type attributes.
> (And rename the 'id' attribute on the 'rule' element to 'xlink:href'.)
> In practice, this would mean that we add an 'id' attribute to 
> 'technique' (do we need a naming convention for this ID?) and a 
> 'techrefs' attribute to 'location'. (These new attributes would be 
> optional in TCDL 2.0, but we can make them obligatory in our usage 
> document.)
> The attachment sc3.1.1_l1_001_20061129_modelA.xml illustrates this 
> model.
> 
> 
> Model B: nesting 'locations' inside 'technique'
> 
> The rationale for this change is that locations can be seen as 
> properties of a technique.
> Compared to model C (nesting 'techniques' inside 'location'), model B 
> also has the advantage that it is not necessary to repeat the 
> 'technique' element for each location where the technique is used. It 
> was also pointed out however, that there should be only one instance of 
> each technique or failure, because test samples should be atomic.
> The attachment sc3.1.1_l1_001_20061129_modelB.xml illustrates this 
> model.
> 
> 
> Model C: nesting 'techniques' inside 'location'
> 
> The rationale for this model is that locations identify where barriers 
> occur and that 'techniques' provides additional (outside TSD TF: 
> optional) information about these locations. Outside TSD TF, not very 
> location or barrier will map to a technique or failure documented by 
> WCAG 2.0, so other users may not want to nest 'locations' inside 
> 'technique'.
> (I have not created an example for this model.)
> 
> 
> [1] http://lists.w3.org/Archives/Public/public-wai-ert-tsdtf/2006Nov/
> 0029.html
> [2] http://lists.w3.org/Archives/Public/public-wai-ert-tsdtf/2006Oct/
> 0024.html
> [3] "Re: Minimum number of techniques in metadata": http://lists.w3.org/
> Archives/Public/public-wai-ert-tsdtf/2006Oct/0072.html
> 
> Best regards,
> 
> Christophe Strobbe
> 

-- 
Shadi Abou-Zahra     Web Accessibility Specialist for Europe |
Chair & Staff Contact for the Evaluation and Repair Tools WG |
World Wide Web Consortium (W3C)           http://www.w3.org/ |
Web Accessibility Initiative (WAI),   http://www.w3.org/WAI/ |
WAI-TIES Project,                http://www.w3.org/WAI/TIES/ |
Evaluation and Repair Tools WG,    http://www.w3.org/WAI/ER/ |
2004, Route des Lucioles - 06560,  Sophia-Antipolis - France |
Voice: +33(0)4 92 38 50 64          Fax: +33(0)4 92 38 78 22 |

Received on Thursday, 30 November 2006 02:34:40 UTC