This wiki has undergone a migration to Confluence found Here
Difference between revisions of "Interaction Versioning"
Jump to navigation
Jump to search
| Line 1: | Line 1: | ||
| − | + | {{MnM Open Hot Topic}} {{Lore}} | |
| − | + | ==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: | Artifacts using traditional identifiers (SSDD_AAnnnnnnRRvv) are assigned versions under two circumstances: | ||
| Line 24: | Line 33: | ||
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. | 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. | ||
| − | |||
| − | |||
Revision as of 22:44, 3 July 2006
This page documents an Open MnM Hot Topic, i.e. a methodology issue requiring a resolution from Modeling and Methodology.
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.
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". The version indicates "all infrastructure stuff that was normative as of the point and time the normative edition was released". For early adopters, it could be one of the development editions or an equivalent "packaged release" by a particular Realm.
- 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.
