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


Help: OASIS Mailing Lists Help | MarkMail Help

tag-comment message

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

Subject: Dealing with spec versions in TAs (and metadata)

I see in Stephen's latest missive ("Editorial Memo: Multiple 
specifications, etc") that you want better text about versions and how to 
handle multiple versions in the TAs. Please recall my email to the comment 
list dated 5 March 2008. I brought to your attention a mechanism we (OASIS 
XSLT testing TC) defined for test case metadata that could apply equally 
well to test assertions.

>3. There is a placeholder for "Identifying Versions" in 3.2. I think the 
first paragraph should point out that while a spec document is produced 
anew for each version, that does not require that a set of TAs be produced 
anew. The TAs can cross several spec versions as long as they have the 
proper version data. 

>Back when I was working on the OASIS TC on XSLT conformance testing, we 
devised two separate values: 
VersionAdd: the lowest numerical version to which the test applies. 
(Absence of this value implies the default of 1.0) 
VersionDrop: if present, it is a number higher than VersionAdd (or 1.0) 
and indicates the lowest version number to which the test does NOT apply. 
Numbering it this way allows a version like 2.3 to be issued after 3.0 
without disturbing cases that no longer apply as of 3.0. If we had instead 
used the highest-number version to which it does apply, in this example we 
might have given the value 2.2 to those cases that would not apply to 3.0, 
but the cases may well have applied to 2.3, when 2.3 was issued.

I hope that helps you resolve the issue.
.................David Marston

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