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

Hi Shadi,

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

Could you elaborate on why you dislike option A?

Regards,
 CI.
 
> 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 Monday, 4 December 2006 14:03:14 UTC