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

 


Help: OASIS Mailing Lists Help | MarkMail Help

tag message

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


Subject: RE: [tag] Groups - TA Anatomy V0.4 (AnatomyTA-v04.doc) uploaded


But this does seem to clash somewhat with the strong use case of
the practice of copying items from the spec straight into the TA
(strong in that we agree it avoids the possibility of varying the
normative expression of the spec requirement item).

For example the SOAP spec we mention on the Wiki
http://www.w3.org/TR/2003/REC-soap12-testcollection-20030624/

That seems to be one of the main use cases for the 'prose' element
of the model.

Also there is the use of the Ref to the spec item which was agreed
could and maybe should be used to avoid redundancy. Since I was
concerned that the links to IDs of the spec items could be weak and
prone to breaking so argued for including actual prose too, maybe
there is a possible best practice here to use a Ref + predicate
rather than Ref + prose, so avoiding those RFC2119 keywords.

But maybe there is a case though for recommending against the use of
the RFC2119 keywords in the 'flow' where there is more likelihood of
a use of the flow for automated test case generation which would
require predicates formalised with a predicate expression that XQuery,
XPath or OCL, etc, might provide.

-Stephen

Quoting "Durand, Jacques R." <JDurand@us.fujitsu.com>:

>
>>> A test assertion ignores the keywords MUST, SHOULD, MAY because its
> focus is on the
>>> feature to be verified on the item under test.
>
>> I quite disagree with this statement. IMHO a test assertion MUST
>
> The intent behind this ban of RFC2119 keywords was primarily (recalling
> here the outcome of the F2F on this topic):
>
> - those keywords, when used in the referred specification requirement
> (to be addressed by the TA), have no reason to appear in the TA itself.
> In other words, whether a normative statement in the referred
> specification is a MUST, SHOULD or MAY, does not affect the way the TA
> is written - it only affects the way the result of this TA is
> interpreted in  a broader conformance context (e.g. a conformance
> profile).
>
> - The TA states an (abstract) test operation, and what is the fail/pass
> condition(s). The operation outcome is of predicative nature: either
> some effect (behavior or condition) is observed, or not. No room for
> MUST, SHOULD or MAY here (unless we have a convincing example where
> these help?). Now, an effect that actually occurs (predicate = "true")
> can be interpreted as a failure by the TA ("negative" TA) or as a
> success (pass).
>
> Does this clarify the point? It seems we agree that there is a mandatory
> nature in the association: {observed effect, TA outcome (fail/pass) }
> but it needs not use MUST keyword to be stated.
>
> -Jacques
>
>
> --
> Dave Pawson
> XSLT XSL-FO FAQ.
> http://www.dpawson.co.uk
>





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