Re: a few questions to kick-off the discussion

[david_marston@us.ibm.com]

I think that a TC should only be formed if it intends to produce a design 
for machine-processable test assertions, which I presume means an XML 
vocabulary. This doesn't need to be a new vocabulary (or "tag set" if you 
prefer that term) if an existing one, or combination of existing ones, can 
be made to work. I will soon be investigating SBVR, which probably has 
useful ideas.

>Should we claim applicability to * all*  OASIS specs?
>how to cooperate with other orgs (W3C, WS-I?) in order to produce a guide 
that is consensual beyond OASIS.

I was on the earlier OASIS Conformance TC, which was looking beyond OASIS. 
I think the scope should be:
Produce a system for expressing test assertions for any specification 
whose implementations can be tested by automated-testing software.
This means that it applies to most OASIS and W3C specs, but not 
necessarily all, and applies to specs from many other "standards" bodies. 
The specs do not have to specify software or data, but can apply to 
anything that can be manipulated by software.

>Should the abstract model be ?branched? into more concrete sub-models 
more appropriate for different types of tests / types of specs?

I think that we should assume that branching will happen. Try to be 
universal, but when the model reaches a division point, branch.

>Can we identify cases where TAs have been automatically generated from 
the spec material?

Sure, but also cases where the spec material was automatically generated 
from the TAs, and cases where the two can be reconciled easily when placed 
side-by-side.

>the scope of the deliverable...

I think we need to discuss TA identifiers and how they would be used. In 
particular, existing work on test case metadata would probably want to 
intermix with TAs, but not necessarily in a structure as simple as one 
test case exercising one TA (and referencing just one in its metadata).
.................David Marston
IBM Research