ITS Acceptance Factors

INM has an action item to create a list of sucess/acceptance requirements for an Implementable Technology Specification (ITS). The aim is not to exhaustively define the characteristics of ITSs, but to provide guidance what the most important acceptance criteria are for a new ITS to be accepted as a workitem by the Infrastructure and Messaging TC (ideally the list should not exceed 10 acceptance criteria). The basic checklist consist of:

• In general the ITS SHALL define how to represent instances of RIM objects. The primary aim of the representation is for the exchange of information between systems. It covers ISO levels 6 and 5.
• The ITS proposal must address implementation concerns, and describe how it conforms to industry best practice for use of the technology in question.
• The scope of the ITS need not extend to all RIM derived objects, its scope may be limited to a well defined subset of RIM derived models, in which case the ITS SHALL clearly identify this limitation.
• The process of creating the representation of instances of RIM objects SHALL be derived solely from non-optional specifications/models that are produced by the HDF. If the process requires specifications/models that are not currently mandated and produced by the HDF, then those that bring forward the ITS SHALL propose a change to the HDF.
  • Adoption of the proposed changes as a workitem by the HDF Project and a commitment of resources by those that submitted the changes to work on any remaining HDF issues are requirements for the ITS to be considered as a workitem for INM. The aim is to avoid the situation where an ITS is (partially) based on FooBar diagrams/models when those FooBar diagrams/models are not part of the standard development process for abstract models.
• The ITS SHALL maximize the preservation of the semantics of the RIM derived objects given the constraints as specified in the scope of the ITS as well as the constraints of the technology or encoding mechanism used by the ITS.
• Those that bring forward an ITS SHALL provide statements of at least 5 member organizations that they will implement the ITS within a reasonable timeframe of it being initially published.
• For non-trivial ITSs tooling will be required to transform RIM-derived models into its encoded format. A Beta version of these tools, as well as commitment to support these tools for a reasonable initial timeframe SHALL be presented to the committee jointly with the proposed ITS itself.

Notes

1. When reviewing/creating these criteria, keep in mind that they should be applicable to ITSs of varous types: the XML ITS, a (hypothetical) ER7 ITS pipe/bar ITS, a (potential) Corba or Java object ITS, the potential ASN.1 ITS, the (existing) UML Release 1 ITS, the (proposed) UML Release 2 ITS, as well as an (unlikely) clay tablet ITS. The encoded representation format may be a string, an object, or an API call.
2. The criteria will be retrospectively applied to the existing ITSs, which may lead to changes. (e.g. the XML ITS needs to document what parts of the abstract models are not supported by the XML Schema it uses as a representation).
3. There are precedents for ITSs with a limited scope: the XML ITS which doesn't support all of the constraints possible in the abstract model, or UML Release 1 ITS which describes the representation of data types, and doesn't describe the representation of structures.