ISO/IEC JTC1/SC32/WG2-EM0112-013

                                                                                                                 Date: 2001-12-12

                                                                                                                       REPLACES: -

Proposed replacement for Conformance Clause

Source:  Frank Farance

 

6 Conformance

 

In this Standard, "shall" is to be interpreted as a requirement on an implementation; conversely, "shall not" is to be interpreted as a prohibition.  If a "shall" or "shall not" requirement is violated, the behavior is undefined.  Undefined behavior is otherwise indicated in this Standard by the words "undefined behavior" or by the omission of any explicit definition of behavior.  There is no difference in emphasis among these three; they all describe "behavior that is undefined".

 

This part of this standard prescribes a conceptual model, not a physical implementation.  Therefore, the metamodel need not be physically implemented exactly as specified. However, it must be possible to unambiguously map between the implementation and the metamodel in both directions.

6.1 Conformance level

 

The following sub-clauses define strictly conforming implementations and conforming implementations.  In the context of conformance, the terms "support", "use", "test", "access", and "probe" are defined in sub-clauses 5.5 [Application conformance] and 5.4 [Bound metadata set conformance].

6.2 Caveat

 

Conformance needs to be considered in the context of the roles and responsibilities of registration authorities, as covered by Part 6: Registration of data elements.

 

Extended conformance of systems requires formalisation of procedures, agreement of roles and responsibilities between parties, and guidelines addressing use of software products and conversions from other systems. The formalisation of these aspects must be consistent with the conformance requirements in the following clauses, and roles of registration authorities as set out in Part 6.

6.3 Rationale

 

The distinction between "strictly conforming" and "conforming" implementations is necessary for addressing the simultaneous need for interoperability and the need for extensions.  Extensions are motivated by needs of users, vendors, institutions, and industries.

 

6.4 Strictly conforming implementations

 

A strictly conforming implementation:

 

1) shall support all mandatory, optional and conditional data element attributes and relationships;

 

2) shall not use, test, access, or probe for any extension features nor extensions to data element attributes;

 

3) shall not exceed limits nor smallest permitted maximum values specified by this Standard; and

 

4) shall not interpret nor allow the production of data element attributes that are dependent on any unspecified, undefined, or implementation-defined behavior.

 

NOTE     The use extensions to data element attributes may cause undefined

behavior.

 

6.5 Conforming implementations

 

A conforming implementation:

 

1) shall support all mandatory and optional data element attributes;

 

2) as permitted by the implementation, may use, test, access, or probe for extension features or extensions to data element attributes;

 

3) as permitted by the implementation, may exceed limits or smallest permitted maximum values specified by this Standard; and

 

4) may interpret or allow the production of data element attributes that are dependent on implementation-defined behavior.

 

NOTE 1: All strictly conforming implementations are also conforming implementations.

 

NOTE 2: The use extensions to data element attributes may cause undefined behavior.