Fwd: Re: [tag-comment] Dealing with spec versions in TAs (and metadata)

["Stephen Green" <stephen.green@documentengineeringservices.com>]

Forwarded from comment list

Thanks David

Steve

---------- Forwarded message ----------
From: david_marston@us.ibm.com
To: "Stephen Green" <stephen.green@bristol.gov.uk>,
tag-comment@lists.oasis-open.org
Date: Tue, 15 Jul 2008 14:28:06 -0400
Subject: Re: [tag-comment] Dealing with spec versions in TAs (and metadata)
>When and where would the values for VersionAdd and
>VersionDrop be provided? I guess these won't be known
>at the time the TAs are first written. How did you cater
>for versions of specs written subsequent to the TAs being
>written?

Where: on each individual TA
When: that takes more explaining; read on...

If there is a new version of a spec, we presume that it alters the old
spec in some way that is amenable to testing (and TAs). Therefore, a
coherent set of TAs can be defined as applying to a particular spec
version or range of versions. To cover a range, the later specs must
be designed to be backwardly compatible to the earlier versions, at
least to a great extent. For example, the set of TAs for version 1.4
of a spec consists of all the TAs issued in previous versions 1.0 to
1.3, plus new TAs for version 1.4, *if* there was perfect backward
compatibility. If not, some TAs from earlier versions may have to be
dropped.

Envision one big pool of TAs. To extract the the TAs that apply to
version X, you take all those whose VersionAdd is less than or equal
to X and whose VersionDrop, if specified, is greater than X.

With that as background, the "when" formula for VersionAdd is simple:
If the TA regards a feature from version 1.0, the VersionAdd
attribute is optional but could be present and set to 1.0.
If the TA regards a feature that originated in version A (>1.0),
then presumably the TA was written concurrent with the release of
the version A spec, so its VersionAdd attribute is set to A and it
is thrown in the pool with all the older TAs.

The "when" formula for VersionDrop is to go back and edit TAs that
already exist in the pool. In every case where version B (>1.0) drops
a feature that had previously existed, the TAs that asserted the old
behavior must have a VersionDrop attribute added, set to B.

I believe that this satisfies the goal that TAs span versions and need
not be written from scratch for every new version.
................David Marston


--
Stephen D. Green

Partner
SystML, http://www.systml.co.uk
Tel: +44 (0) 117 9541606
Associate Director
Document Engineering Services
http://www.documentengineeringservices.com

http://www.biblegateway.com/passage/?search=matthew+22:37 .. and voice