Re: Location of 'techniques' in TCDL

Hi Shadi,

Quoting Shadi Abou-Zahra <shadi@w3.org>:
> 
> Hi,
> 
> I agree with Daniela's point about potential ambiguity. My
> understanding 
> is that each "run" of a test must map to exactly one technique.

For the taskforce, but not necessarily outside the taskforce.

 
> The "run" consists of the rule, the technique, and the expected 
> outcome.
> These are one entity, and a technique is actually a (WCAG
> 2.0-specific) 
> refinement of a rule.
> 
> My proposal would be to keep the technique element within the
> locations 
> element but to allow no more than one instance per locations element
> 
> (for this Task Force, a technique must be provided). Hence, each 
> location within the locations element would mark exactly one instance
> of 
> the outcome of a "run".
> 
> The way to point to multiple techniques from within one test sample 
> would be to have multiple locations element per rule element. I am
> not 
> sure if this is supported by TCDL 2.0 though. 

The idea was to use 'locations' to group instances of 'location' and to 
use 'techniques' to group instance of 'technique'. So repeating 
'locations' looks strange to me (and is currently not allowed in TCDL); 
hence the idea to keep 'techniques' outside 'locations' or to put it 
inside 'location'. 
Putting 'techniques' inside 'locations' sounds like a 'neither fish, 
flesh, nor good red herring'-solution: if we care about the 
relationship between technique(s) and location(s), why not put 
'techniques' inside 'location'; if we don't care, why not put 
'techniques' outside 'locations' and avoid suggesting a relationship 
between a specific location and a specific technique? Let's take a 
clear stance, not something in between.


> Here is an example:
> (...)
> 
> A different approach all together would be to have a new rule element
> 
> for a new technique (= new "run"). However, I think there is a 
> restriction on how the rule elements are combined in TCDL 2.0.

True, the idea is not to repeat the ID/xlink:href for the same SC.

Best regards,

Christophe

> 
> 
> Regards,
>    Shadi
> 
> 
> cstrobbe wrote:
> > Hi Daniela,
> > 
> > Quoting Daniela Ortner <Daniela.Ortner@jku.at>:
> >> you wrote that with the first option ('techniques' in 'locations'
> >> after
> >> 'location') we would be able to describe how a location and a
> >> certain
> >> technique relate. The current schema would allow the following:
> >>
> >> <locations>
> >>    <location>
> >>    </location>
> >>    <location>
> >>    </location>
> >>    ...
> >>    <technique>
> >>    </technique>
> >>    <technique>
> >>    </technique>
> >>    ...
> >> </locations>
> >>
> >> But what does that indicate? That the first <location> belongs to
> >> the
> >> first <technique>? 
> >> I see no possibility to express relationship between a location
> and
> >> a
> >> technique from this example.
> >>
> >> Wouldn't it be better to construct something like:
> >>
> >> <locations>
> >>    <location>
> >>       <technique>
> >>       </technique>
> >>       <technique>
> >>       </technique>
> >>       ...
> >>    </location>
> >>    <location>
> >>       <technique>
> >>       </technique>
> >>       <technique>
> >>       </technique>
> >>       ...
> >>    </location>
> >>    ...
> >> </locations>
> >>
> >> Looking forward to read your thoughts on that...
> > 
> > That idea also crossed my mind, but we already have EARL pointers 
> > inside location (with an <xs:all> group). If we want to go down
> this 
> > road, it would look like this:
> > 
> > <locations>
> >   <location>
> >     <!-- EARL pointers here -->
> >     <techniques>
> >       <technique />
> >       <technique />
> >     </techniques>
> >   </location>
> >   <location>
> >     <!-- EARL pointers here -->
> >     <techniques>
> >       <technique />
> >       <technique />
> >     </techniques>
> >   </location>
> > </locations>
> > 
> > Do people like this approach?
> > 
> > Best regards,
> > 
> > Christophe
> > 
> >> Regards,
> >> Daniela


-- 
Christophe Strobbe
K.U.Leuven - Departement of Electrical Engineering - Research Group on 
Document Architectures
Kasteelpark Arenberg 10 - 3001 Leuven-Heverlee - BELGIUM
tel: +32 16 32 85 51
http://www.docarch.be/ 

Disclaimer: http://www.kuleuven.be/cwis/email_disclaimer.htm

Received on Wednesday, 18 October 2006 11:06:18 UTC