This wiki has undergone a migration to Confluence found Here
Difference between revisions of "Interaction Versioning"
Jump to navigation
Jump to search
Rene spronk (talk | contribs) |
Rene spronk (talk | contribs) |
||
| (17 intermediate revisions by 3 users not shown) | |||
| Line 1: | Line 1: | ||
| − | + | {{Lore}} | |
| + | ''See the [[Talk:{{PAGENAME}}|discussion page]] for discussions.'' | ||
| + | |||
| + | ==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: | ||
#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 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 | + | #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: | Caveats: | ||
*Assumption is that 'semantically backward compatible' means not necessarily schema-compatible, but doesn't allow for complete remodeling of content either. | *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. | + | *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. | *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. | 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. | ||
| − | + | 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. | ||
Latest revision as of 04:50, 24 October 2006
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.
See the discussion page for discussions.
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.
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.
