Semantic Backward Compatibility

Resolution and next steps

MnM Call 2006/06/30:

• Moved by Woody Beeler that the wiki content be endorsed as written
• second Lee Coller (8:0:0)

Actions:

• This documentation needs to be incorporated in the "v3 statement of principles" and reballoted (potentially with other changes) as part of those principles
  • To be added to the agenda for the September WGM
• Woody will forward this documentation to the ARB to inform their discussions on subtantivity.

Static Models

(from an MnM discussion and decision during the Sept 2005 WGM)

• Backward model compatibility does not in any way guarantee backward structural compatibility with any given ITS.
  • Structural compatibility includes the ability to parse and validate instances and such issues as naming of elements.
  • Model compatibility reflects the ability to safely interpret data received based on previous models
• The definition of structural compatibility between model-compatible versions of an instance within an ITS and any ability to translate between versions within an ITS is the responsibility of each ITS.
• It is necessary, but not sufficient, for model compatibility that changes comply with extension and restriction rules as defined in the Localization and Refinement specification, assuming the rights defined for international affiliates. (I.e. extensions are allowed, provided the international affiliate rules are followed.)
• Objective of backward model compatibility is that a receiver expecting an 'old' version will not misinterpret content sent from a new version, specifically:
  • a receiver who ignores all content added in the new version will correctly interpret the meaning of the data that would have been present in the previous version despite their inability to process the newly added elements
  • a receiver must find all content defined in the previous version that is necessary to interpret the instance (this content should presumably have been defined as mandatory in the previous version.)
  • For example, classes must not be extended by adding negationInd, adding inversionInd, introducing or changing constraints on contextConduction, adding default values, introducing updateModes, etc. because these changes could result in a change to the interpretation of data supported with previous versions. (Note: The list of attributes which affect interpretation of data listed here is not necessarily exhaustive.)
• From a model compatibility perspective, receivers should ignore elements and repetitions that were not available in the version of a specification they support.
• Backward model compatibility does not guarantee that a sender of an 'old' version will interoperate with a receiver requiring a 'new' version. Receivers are responsible for deciding what versions to support and will declare their support for versions in their conformance profiles.
• Changes between models that violate model backward compatibility must be defined as completely new artifacts rather than new versions of previous artifacts.

Comment: The definition given here of backwards compatibility seems at odds with the definition the W3C Technical Architecture Group is giving in http://lists.w3.org/Archives/Public/www-tag/2004Nov/att-0071/versioning-part1.html where it says: "A language change is backwards compatible if newer processors can process all instances of the old language" whereas here the opposite is said: "Backward model compatibility does not guarantee that a sender of an 'old' version will interoperate with a receiver requiring a 'new' version.". Also in this doc it says: "Objective of backward model compatibility is that a receiver expecting an 'old' version will not misinterpret content sent from a new version", where the W3C TAG uses this requirement in its definition of forward compatibility: "Forwards compatibility means that a newer version of a producer can be rolled out in a way that does not break existing consumers." Marc de Graauw 8 Jul 2006

Requirement-Definition models

• Backwards-compatibility is out-of scope for all requirement-definition artifacts such as storyboards, storyboard examples, domain analysis models, etc. The rationale is that requirements-definition artifacts are not binding on implementations.

Dynamic model

• Interactions are backward compatible provided that the trigger events, bound static models and receiver responsibilities are backward compatible.
• Trigger events are backward compatible only if the event tied to the trigger event is unchanged. All other changes require a new trigger event.
  • Changes to state transitions is not backward compatible
  • Changes to trigger event type (environment vs. interaction vs. state-transition) is not backward compatible
  • Changes that modify the filter or scope of the types of state transitions or environmental occurrences that fire the trigger are not backward compatible.
  • Changes to examples, descriptive names or other comments which do not modify the filter or scope are backward compatible and merely change the version.
• Adding receiver responsibilities to an interaction is backwards compatible.
• Removing receiver responsibilities from an interaction is not backwards compatible.
• Changing the guidance for when a receiver responsibility should be fired is not backwards compatible. For example, if you add a new receiver responsibility and as a result must update the guidance for when the other receiver responsibilities may be invoked, then the change is not backwards compatible and a new interaction would need to be defined.
• Model compatibility is not defined for application roles