RE: [tag] Section 3.7 Specification Versions

["Durand, Jacques R." <JDurand@us.fujitsu.com>]

Paul:

 

Looks OK to me, overall.

More comments inline.

 

Jacues

---

From: Paul.Rank@Sun.COM [mailto:Paul.Rank@Sun.COM]
Sent: Wednesday, September 24, 2008 3:38 PM
To: tag@lists.oasis-open.org
Subject: [tag] 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.
 

<JD> could we have two or more Add-Drop intervals in the same TA?

 
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. 

 

<JD> The above paragraph could be made easier to read by showing snippet(s) of example:

 tag: VersionAdd = rev15
 tag: VersionDrop = rev19

 means that the TA applies from rev15 up to rev18 included. 


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.  
 

<JD> This should be compared with the use of  "lists" as the other grouping mechanism.

Also, the advantage of defining Add-Drop intervals makes it easier to manage the updates related to a new version / revision, as by default a TA that applied to the previous version will apply automatically to the new one, same for NOT apply.

 

 
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. 

 

<JD> I would not worry about the above modification case: a modified TA is a new TA ... Why not just say that the TAs themselves probably should not be versioned.

<!--[endif]-->