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: Section 3.7 Specification Versions


Hi Stephen and all,
The following is my revision to section 3.7 Specification Versions.  Comments?
Thanks,
Paul
===================================
3.7 Specification Versions


Where a specification is the basis for test assertions there needs to be consideration of how to support further versions and maybe any previous versions of that specification.  One solution is to create a set of test assertions for each version.  The references to specifications may include the identification of the precise specification version but this may restrict that test assertion to just one version of a specification. Such a simple strategy is less than ideal as it results in a need to re-author the test assertions each time there is a new specification version.

Another method of dealing with multiple specification versions is to create a repository of test assertions for a specification and properly tag each test assertion for the versions of the specification where it is valid.
   This can be accomplished by introducing 2 tags, VersionAdd and VersionDrop. 

   tag: VersionAdd: the lowest numerical version to which the test assertion applies.
   tag: VersionDrop: the lowest numerical version number to which the test assertion does NOT apply.

Both VersionAdd and VersionDrop are optional tags.  The absence of both tags would mean that the test assertion is valid in all specification versions.  If only a VersionAdd tag exists and its values is X, the test assertion will be valid in version X of the specification and all subsequent versions.  If only a VersionDrop tag exists and its values is Y, the test assertion will be valid in all versions of the specification prior to version Y.  If both VersionAdd and VersionDrop tags exist, the test assertion will be valid in version X and all subsequent version up to (and not including) version Y.  Based on these rules, one can easily generate the set of test assertions that apply to a specific version of the specification.

Care must be taken when going from one version of a specification to another.  The test assertion author must identify all test assertions that are the same between versions, that are dropped from one version, that are added to one version, and that modified between versions.   Test assertions that are the same, are dropped, or are added can easily be handled with the VersionAdd and VersionDrop tags. 

Test assertions that are modified are trickier to handle.  One could treat the modified test assertions as two separate test assertions and tag them with the appropriate VersionAdd and VersionDrop tags.  Unfortunately, this approach does not provide any indication that the updated assertion is related to the test assertion in the prior specification.



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