Interaction Versioning

Resolution and Actions

20060630 MnM call:

• Woody agreed to take this up with publishing and work towards getting document updated

20060605 MnM call:

• Motion: (Woody Beeler): Accept the Wiki content as of 20060605 (see history page), in principle, and update this document in the near future to reflect:
  • (a) the impact of this on the publication of schemas in ballots and Normative Editions;
  • (b) its relationship to the process of artifact deprecation; and
  • (c) include guidance to committees on when to create new interactions as opposed to simply creating new versions.
  • Once updated, we will seek formal endorsement of the completed document on a subsequent call.
• Second (Connor) - 5-0-2)

Issue

Artifacts using traditional identifiers (SSDD_AAnnnnnnRRvv) are assigned versions under two circumstances:

1. When the artifact passes membership and is Semantically Backward Compatible with the previous version. If not semantically backward compatible, you *must* assign a new identifier, not a new version.
2. When dependencies of the artifact (trigger events, wrappers, payloads) have been assigned new versions, the parent of those dependent artifacts will be assigned a new version as part of the normative release.

Caveats:

• Assumption is that 'semantically backward compatible' means not necessarily schema-compatible, but doesn't allow for complete remodeling of content either.
• Non-semantically compatible changes in approach to Datatypes, RIM, Vocabulary and/or ITS could result in a mass version change to all artifacts.
• The version specified in the instance interactionId attribute must be the same as the interaction version published in the edition specified in the instance versionCode attribute.

Implication: The complete version of all message types, CMETs, Vocabulary, Datatypes and ITS is fully pre-coordinated in the version of the identifier combined with the Release version.

(clarification in a later e-mail)

Not all versions are pre-coordinated in the interaction version. There are two separate versioning activities that go on:

• infrastructure versioning (CMETs, datatypes, vocabulary, transports) which is communicated using the "version" attribute and has values such as "2006NormativeEdition". See Interaction Conformance and Versioning - Implementation Issues for details.
• Interaction versioning (trigger events, message payloads, receiver responsibilities) which is communicated using the version component of the interaction id. A new interaction version is issued whenever an interaction passes normative ballot, and binds specific versions of trigger events, message payloads & receiver responsibilities.

In other words you can use new CMETs and datatypes and vocabulary just by declaring a different version attribute without creating a new version of the interaction.

Discussion

Comment: The second bullet "Non-semantically compatible changes ... could result in a mass version change ..." should probably be "Semantically backward compatible changes ... could result in a mass version change ..." since above it says "if not semantically backward compatible, you *must* assign a new identifier, not a new version." Marc de Graauw 9 Jul 2006

In other words: a non-semantically bacwards compatible change to the infrastucture would have to result in new interactions, not in new versions of interactions. A non-semantically bacwards compatible change to the infrastucture results automatically in an interaction that is non-semantically bacwards compatible. It seems the above (approved) text has a logical flaw in it that has yet to be resolved. Rene spronk 23:23, 9 Jul 2006 (CDT)