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

 
Hi again,

> Using ID and IDREF attributes seems much more difficult to 
> process. Also more difficult to read and so more prone to 
> bugs. Unless there is a case for significant benefits, then I 
> suggest we don't complicate things.

I agree it's more difficult to process, but also think it's the most robust and flexible solution (the original idea was to "emulate" the ID mechanism of RDF). Anyway I think we could perfectly manage with one of the other solutions for the purpose of this TF if we want to avoid excessive complication.

> For this group our primary target is to describe the 
> relationship of a sample to the respective technique. So 
> nesting (different types of) location pointers under each 
> technique makes most sense (option A).
> 
> However, since option A is quite restricted to the (current 
> draft) WCAG 2.0 model, we may choose to go for a less 
> technique-oriented approach. 
> Option B is probably more verbose since the technique would 
> be repeated in each (different type of) location pointer but 
> I could live with it.

Well, I suppose you mean B and C instead A and B respectively. In this case, I agree that option B may be WCAG 2.0 model tailored, but I don't see any problem since WCAG 2.0 Test Samples is our aim.
Anyway you can call it technique, success criteria, checkpoint or whatever, IMO the model remains valid as long as you are able to map to some kind of rule (and you should always be able to do so). This is why I prefer option B instead of C (I don't see any additional benefit in C)

Regards,
 CI.
 
--------------------------------------

Carlos Iglesias

CTIC Foundation
Science and Technology Park of Gijón
33203 - Gijón, Asturias, Spain 

phone: +34 984291212
fax: +34 984390612
email: carlos.iglesias@fundacionctic.org
URL: http://www.fundacionctic.org


> Carlos Iglesias wrote:
> > 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 |
> >>
> >>
> > 
> > 
> 
> -- 
> 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 15:30:16 UTC