OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

tag-discuss message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: the role of an XML mark-up for TAs


>Lin Ju Comments: The guideline covers the TA model and we can use XML mark-up as example.

 

>I think that a TC should only be formed if it intends to produce a design for

> machine- processable test assertions,

 

> dp: Not all wanted testing is automated. Manual intervention is often necessary

> in order to fully test an object,

 

There seems to be support on this list for having an XML mark-up within scope of the TA guide work.

But the expectations placed on this mark-up are not clear yet… I think it is worth spending some time on it – because if a TC is chartered there will be IPR implications on the status of this mark-up.

I like to think about it from the viewpoint of what it could be used for. I see three options so far:

1. methodology helper - Just an XML binding to the TA model as good as any other,  that provides users with a more concrete framework to write their TAs (i.e. part of the methodology support). A kind of methodology-supporting script. Not necessarily normative.

2. publishing source - Like (1), plus it is a normative representation mostly intended for display and HTML publishing, i.e. it is expected that XSLTs will be made available and reusable for it. Pretends to be THE publishing source format.

3. Test suite driver - Like (2) , plus it is designed to actually be processed by test tools. The mark-up will allow for grouping TAs in units that could control the execution of test suites. Note I am not saying these TAs are executable: there will usually be a need for an additional set of * test cases* that is executable – but the TAs would be used as a high-level representation of a test suite, both human-readable and machine-readable, indicating which related test case must be executed, and possibly defining execution outputs more precisely, e.g. error messages.

4. Other?

So the design of a TA mark-up may vary depending on these. Also, the grouping of TAs in larger entities (e.g. conformance profiles or levels) is another aspect of the mark-up, that is more or less important to address depending on above options.

I’d like to hear what people think is more useful or what above option they would consider worth the work. E.g. do you consider (3) the  only worthy goal? Or is achieving (2) or (1) equally useful?

Thanks,

Jacques

 



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]