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

   Date: 2001-12-21

                     

Proposal to resolve several comments on clause 6

Source:  Tim Bourne, based on document EM0112-013R2 and VIC-019C

This proposal takes 013R2 as its starting point, and adds back those parts of VIC019C that are not covered there and still seem to be relevant.

Changes from WG2-EM0112-013R2

1.       Make explicit, as in VIC019C, the distinction between several different choices that must be made in assessing conformance.

2.       Make clearer the precise meaning of levels of conformance and of obligation..

Proposed replacement for Conformance Clause

Begin Text

6 Conformance

In this part of ISO/IEC 11179, "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 part of ISO/IEC 11179 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".

PROPOSER’S NOTE: Isn’t the above covered adequately in ISO Directives? It could also be argued that Part 3 no longer specifies “behaviour” at all.

This part of ISO/IEC 11179 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.

This part of ISO/IEC 11179 also prescribes a list of basic attributes for situation where a full conceptual model is not required or not appropriate.

Conformance may be claimed to the either the conceptual model, or the basic attributes or both; see 6.2.

Conformance may be expressed in terms of a number of areas, in each of which choices must be made.

6.1          Degree of Conformance

The distinction between "strictly conforming" and "conforming" implementations is necessary to address the simultaneous needs for interoperability and extensions.  This part of ISO/IEC 11179Standard describes specifications that promote interoperability.  Extensions are motivated by needs of users, vendors, institutions, and industries, and:

(1) are not directly specified by this part of ISO/IEC 11179Standard,

(2) are specified and agreed to outside this part of ISO/IEC 11179Standard, and

(3) may serve as trial usage for future editions of this part of ISO/IEC 11179Standard.

A strictly conforming implementation may be limited in usefulness but is maximally interoperable with respect to this part of ISO/IEC 11179Standard. A conforming implementation may be more useful, but may be less interoperable with respect to this part of ISO/IEC 11179Standard.

6.1 Conformance levels

The following sub-clauses define strictly conforming implementations and conforming implementations.

6.1.1 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.1.2 .1 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 part of ISO/IEC 11179; and

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

PROPOSER’S NOTE: Is “interpret” a good word to use here? Would it be clearer to say “shall not recognize nor act on, nor allow …”?

NOTE     The use of extensions to the metamodel or the basic attributes may cause undefined behavior.

6.1. 3 2 Conforming implementations

A conforming implementation:

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

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 part of ISO/IEC 11179; 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 of extensions to the metamodel or the basic attributes may cause undefined behavior.

6.2          Levels of Conformance

An implementation may conform to either of two levels of conformance to this standard:

Level 1: Only those metadata elements, relationships and properties specified in Clause 5 are supported and used;

Level 2: All metadata elements, relationships and properties specified in Clause 4 are supported and may be used.

6.3          Obligation

Properties and relationships specified in this standard are stated to be Mandatory, Optional or Conditional.

For the purpose of conformance, anything specified as Conditional within this standard shall be treated as Mandatory if the associated condition is satisfied, and shall otherwise be not present.

Mandatory properties and relationships shall exist, and shall conform to the provisions of this standard. Optional properties and relationships are not required to exist, but if they do exist they shall conform to the provisions of this standard.

Such obligation is enforced if and only if the Registration Status of the associated metadata elements is Recorded or higher.

6.4          Conformance to prior editions of this Standard

PROPOSER’S NOTE: Does this subclause say enough? Is it useful?

The following are the registry items and their obligation attributes in the ISO/IEC 11179-3:1994 edition of this Standard, and the current longevity attributes:

·         Identifying: Name (mandatory), Identifier (conditional), Version (conditional), Registration Authority (conditional), Synonymous Name (optional, obsolete), Context (conditional)

·         Definitional: Definition (mandatory)

·         Relational: Classification Scheme (optional), Keywords (optional, obsolete), Related Data Reference (optional, obsolete), Type of Relationship (conditional, obsolete)

·         Representational: Representation Category (mandatory, obsolete), Form of Representation (mandatory, obsolete), Datatype of Data Element Values (mandatory), Maximum Size of Data Element Values (mandatory), Minimum Size of Data Element Values (mandatory, obsolete), Layout of Representation (conditional, obsolete), Permissible Data Element Values (mandatory, obsolete)

·         Administrative: Responsible Organization (optional), Registration Status (conditional, obsolete), Submitting Organization (optional), Comments (optional)

Annex F relates the ISO/IEC 11179-3:attributes of the 1994 attributes to the new metamodel.

6.5          Implementation Conformance Statement (ICS)

An implementation claiming conformance to this part of ISO/IEC 11179standard shall include an Implementation Conformance Statement stating:

1)       whether it conforms or strictly conforms (6.1);

2)       whether conformance is to Level 1 or Level 2 (6.2);

3)       what extensions are supported or used.

6.2 6          Roles and Responsibilities for Registration

Conformance needs to be considered in the context of the roles and responsibilities of registration authorities, as covered by ISO/IEC 11179-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 above clauses, and roles of registration authorities as set out in ISO/IEC 11179-6.

End Text

Other changes required as a result of the changes to clause 6

The simplification of clause 6 results in several terms no longer being used.

The following terms and definitions should be deleted from clause 3:

·         consume

·         generate

·         metadata entry application

·         metadata reader application

·         metadata set

·         produce

The following terms and definitions are used elsewhere in the document, so need to be retained:

·         binding – used in clause 1.3.

·         interpret – used in clause 6.1.2 and 6.1.3, but remove the NOTE and Editor's NOTE from clause 3.1.14 (in EM008).