Interaction Versioning
This page documents Lore, i.e. all the facts and traditions about a particular subject that have been accumulated over time, but that have not been documented in a ballot yet.
This page documents an Open MnM Hot Topic, i.e. a methodology issue requiring a resolution from Modeling and Methodology.
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:
- 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.
- 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. That would make sense given the versioning system in place, but it wasn't the intent of those that created the versioning mechanism. Rene spronk 23:23, 9 Jul 2006 (CDT)
