Difference between revisions of "ITS Acceptance Factors"
Rene spronk (talk | contribs) |
Rene spronk (talk | contribs) |
||
| Line 8: | Line 8: | ||
| − | Note: when reviewing/creating these criteria, we have to make sure they apply to: the (existing) XML ITS, a (hypothetical) pipe/bar ITS, a (potential) Corba or Java object 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. | + | Note: when reviewing/creating these criteria, we have to make sure they apply to: the (existing) 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. |
Revision as of 03:34, 12 May 2006
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 INM committee. The basic checklist consist of:
- In general the ITS SHALL define how to represent RIM objects for transmission in messages. It covers ISO levels 6 and 5.
- 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. [Precedents: 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]
- The process of creating the representation of RIM objects for transmission in messages SHALL be based solely on non-optional specifications/models that are produced by the HDF.
- Note: If the process requires specifications/models that are not currently mandated and produced by the HDF, then those that bring forward the ITS should propose a change to the HDF. Acceptance of those changes is a requirement for the ITS to be considered as a workitem for INM.
- 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 should provide statements of at least 5 member organizations that they will implement the ITS within a reasonable timeframe of it being initially published.
Note: when reviewing/creating these criteria, we have to make sure they apply to: the (existing) 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.
