RE: TCDL Draft E (and some updates)


Hi group,
Some comments below...

> > That's what the Extension element type and the extension 
> point are for. 
> > This mechanism allows us to control where such elements can 
> be added, 
> > so that they are added in a controlled way instead of just anywhere 
> > (which would just cause chaos, in my opinion). I have at 
> last written 
> > the section on extensibility of TCDL, where this is explained.
> > 
> > (Note that adding new elements and attributes to the schema 
> can also 
> > be done outside these extensibility points, and that comes 
> obviously 
> > at the price of updating all the existin files.)
> It seems we are provoking a philosophical discussion. I'm 
> happy to leave the Extension element inside for now and see 
> where we get at. However, please include a note that parsers 
> (and validators) should ignore additional elements or 
> attributes that they do not know. Maybe that is already in 
> the extensibility section, I have to check.

Due to the aim of the group (just have some language for Test Samples metadata without starting for the scratch, and not defining a TCDL specification), and the fact that we are going to use the language under a "controlled environment", I wouldn't care too much about the extensibility issue. The simpler the language the best for us.
> > "testElement" and "testElements" would enable us to check 
> how well a 
> > test suite covers certain features, especially 
> accessibility features, 
> > of a technology. This could help the TSD TF to get help and/or test 
> > cases from other working groups (who often have test suites 
> of their 
> > own). I have added a note about this to the spec.
> > 
> > "testElement" is not meant to refer to WCAG, however. References to 
> > success criteria are meant to be in the "rules" section. Does this 
> > require a clearer explanation in the spec?
> Yes, on the last call we agreed to keep it in for now but 
> closely monitor how much discussion and hence resource 
> consumption this feature will cause. There are clear 
> advantages but I also fear a lot more work...

I also agree that is a really nice feature but a lot of added work far from our main objective.

> > (A related issue: there are test procedures in the WCAG techniques 
> > document, but the "rules" section only points to success 
> criteria, not 
> > techniques or failures. It is possible to provide links to 
> techniques 
> > or failures in other TCDL elements, e.g. techComment, because they 
> > allow limited HTML markup, but there is currently no "standard" 
> > mechanism for pointing to test procedures, techniques or failures. 
> > Perhaps we should discuss this in a separate thread.)
> Yes, I agree we should. It is clear that we need to point to 
> the success criteria but equally well we should point to the 
> techniques that were used to evaluate a success criteria 
> using the test case. IMO this should not be a comment but a 
> machine readable pointer.

> >>> (Strictly speaking, it is possible to drop 
> functionalOutcome because 
> >>> the description and purpose elements are sufficiently expressive.)
> >>
> >> I vote for dropping it in the context of this Task Force.
> > 
> > I would keep techComment: it's a handy place for recording 
> user agent 
> > support notes and other technical stuff. I use it a lot in 
> BenToWeb. 
> > If we drop this element, this information would need to go into 
> > 'description'. Any comments?
> You convinced me. There is probably a strong case for being 
> able to record all the nitty-gritty technical comments, stuff 
> that may go beyond a mere description of the test case.

It would be really helpful if you could point to some relevant examples about this.
I tried to find some myself but the only reference I found was [] and apparently it's not working any more.



Carlos Iglesias

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

phone: +34 984291212
fax: +34 984390612

Received on Thursday, 14 September 2006 12:52:06 UTC