Part 1: Model and Methodology

Edition 1

1 - Scope

This part specifies a methodology for managing (generating and maintaining) a schema specification for data to be recorded under the RP 66, V2 format.

This document is intended to:

2 - Definitions

3 - Concepts

A logical model is the conceptual organization of a domain of knowledge: What classes of things are of interest, and what are their characteristics and the relationships between them which are of interest? A logical model is a framework for common understanding of the nature of classes of things, but is not sufficient for communication about individual members of the classes.

An implementation model, also called a schema, is a formalized description of the encoding of information defined by the logical model, typically in terms of a representational model. How are general representational constructs used to encapsulate information about the elements defined in the logical model? A schema must be sufficiently dynamic to meet new requirements, and yet must be sufficiently stable that change requirements are not unnecessarily imposed on the systems which use it.

A representational (or data) model is a description of the specification and representation paradigm to be used. What are the fundamental representational constructs and their organization? How is the schema specified? How is data organized, encoded, stored, and decoded?

The purpose of a schema specification for an exchange format is to enable the exchange of information in some domain of knowledge.

4 - Audience

This document is intended for:

  • Original authors and maintainers of schema specifications.
  • Readers of schema specifications.
  • Developers of schema-neutral RP 66, V2 software layers and systems.
  • It is assumed that the reader has a basic understanding of logical models, and has a particular logical model in mind. No particular modeling formalism is assumed; indeed, the schema specification may itself be the only formal expression of the logical model.

    RP 66, V2 is a general-purpose data exchange mechanism which is not bound to a specific logical model. The purpose for using a standard methodology for schema specification is to enable the implementation of data exchange using model-driven software layers.

    5 - Schema Categories

    Schemas may be categorized as managed, derived, and local.

    A managed schema exists from the definition of its initial edition, through subsequent editions, until all data recorded under it are no longer of interest (i. e., indefinitely). During this life cycle each edition of a schema is expected to meet certain requirements for compatibility or continuity with previous editions. As the logical model and usage requirements change new editions of the schema are developed, subject to these constraints.

    A derived schema is one which is systematically derived or inferred from a formalized logical model according to a deterministic methodology. In this case a human-readable schema specification might not be produced. Furthermore, the schema edition reflects the version of the derivation methodology and the versioning policy under which it is governed. The logical model may be governed under a different versioning policy. Organizations that define derivation methodologies should provide mechanisms to record and identify the author, name, and edition of the logical model from which the schema is derived.

    A local schema is one that is neither managed nor derived but is used for local exchange or storage of data using the data model.

    This document is normatively applicable to managed schemas only.

    6 - Schema Administration

    An organization must have been issued an organization code to publish a managed schema or a schema derivation methodology. Code 999 is reserved for local schema. An organization code is assigned on request, by POSC, which also maintains the most current list of organization codes. Its address is listed at the end of the Foreword.

    The holder of an organization code may publish (editions of) a schema or a schema derivation methodology under that code. An organization that wishes to manage multiple schemas may obtain multiple organization codes. No other constraints apply among schemas, but certain constraints apply between editions of a managed schema. If a schema element is defined under two editions, then it has the same meaning and use in both editions. Elements may be dropped from one edition to the next and new elements may be added, but elements may not be redefined.

    Alternatively, an organization may manage multiple schemas by defining a derivation methodology under an organization code for mapping an appropriate class of logical models into derived schemas.

    In general, it is expected that an organization that publishes a schema or a schema derivation methodology will also publish the specific versioning policy governing compatibility and constraints between editions. Derived schemas editions are determined indirectly by reflecting the logical model edition along with the name and edition of the derivation methodology applied to the logical model.

    7 - Data Model

    RP 66, V2 schema specifications are defined in terms of object types, attributes, and the rules about them. These data model elements are described in detail in Part 2, "Logical Format."

    The specification of an object type includes its name, its semantics, its attributes, and whether its instances have controlled names. No relation shall be assumed between object types in different schemas having the same type names.

    The specification of an attribute includes its label, its semantics, and any restrictions on its count, representation code, units, or value. Unless explicitly stated, no relation shall be assumed between attributes in different object types having the same labels.

    An instance of an object type is constrained by its object type specification. An object may have all, some, or none of the attributes defined for it, and shall not have attributes not defined for it or duplicates of the attributes defined for it.

    An instance of an attribute is constrained by its specification in the object type of the object in which it appears. An attribute has exactly one occurrence of each type of characteristic: label, count, representation code, units, and value. The label identifies the attribute in terms of its definition in the object type. The value is composed of zero or more elements, or occurrences of the data representation identified by its representation code. It has a single count, which is the number of elements in its value. It has a single units value, which applies to each element of the value.

    The logical file is the logical unit of data exchange, and is a collection of objects and other data described by its objects. The object is the unit of data which may be uniquely referenced within a logical file. An object is a collection of the attributes defined for its type, with assigned values. A logical file may contain objects from any number of schemas, and objects may refer to objects in different schemas in the same logical file.

    8 - Schema Specification

    8.1 - Preliminary Part

    The preliminary part of a schema specification may include the following:

  • title page.
  • table of contents.
  • foreword.
  • introduction.
  • 8.2 - Normative Part

    The normative part of a schema specification may include the following:

  • context.
  • title.
  • scope.
  • normative references.
  • authority.
  • sanctioning organization.
  • document preparation, revision, and review committees.
  • proprietary considerations.
  • revision and versioning policies.
  • edition.
  • edition level.
  • summary of this and recent editions.
  • document status (draft or final).
  • definitions.
  • define terminology introduced.
  • normative references to other defining documents.
  • model.
  • definition, presentation, or description of the logical model, or reference to equivalent documentation.
  • schema.
  • definition of object types and their attributes.
  • constraints on objects and attributes.
  • relationships to corresponding elements of the logical model.
  • dictionary.
  • tables of reference values, to which attributes they apply, and their meanings.
  • units.
  • specification of unit model(s) and unit dictionary(ies) used in the schema (if not API-SI units).
  • identification of units model in attribute restriction specifications.
  • normative appendices.
  • 8.3 - Supplementary Part

    The supplementary part of a schema specification may include the following:

  • informative appendices.
  • footnotes.

    8.4 - Object Type Specification

    An object type is specified by providing a unique type identifier, dictionary constraints on the identifier subfield of the name, a set of attributes, and the intended use of the object. An object type specification typically has the following parts:

  • type name.
  • context - a description of the semantics of the object type or reference to a logical model.
  • attribute specifications.

    8.5 - Attribute Specification

    The characteristics of an attribute are its label, count, representation code, units, and value. The formal specification of an attribute includes its label, and may include constraints on the remaining characteristics.

    The formal specification of the set of attributes defined for an object type is presented in a single table, followed immediately by a set of numbered notes. The columns of the attribute specification table are:

  • Attribute Label: a valid IDENT value, unique in the object type.
  • Restrictions: a set of restrictions on the count, representation code, units, or value characteristics of an attribute. Restriction specifications are of the form `q1=r1, q2=r2, ... qn=rn', where `qn' is the characteristic identifier and `rn' is a restriction specification. The characteristic identifier is lower case. When no restrictions apply, the identifier is omitted. Restriction specifications are stated in the order `c=..., r=..., u=..., v=...'.
  • A count restriction is specified as `c={[min1:max1], [min2:max2], ...,[minn:maxn]}', where mink and maxk represent bounds, or `?' if the interval lacks an upper or lower bound. If a single boundary set is specified, the curly braces (`{`, `}') are omitted. If the minimum and the maximum are equal for any boundary range, the square brackets (`[`, `]'), colon (`:'), and second range limit are omitted.
  • The representation code retriction is specified as `r=XXX | YYY | ZZZ', where XXX, YYY, and ZZZ are alternative representation codes. If a single representation code is specified, the vertical bar `|' is omitted. For each representation code, an alternative representation in the same representation code class may be used, but the value shall be representable in one of the specified representation codes.
  • The units restriction is specified as `u=um:uexp', where um identifies the units model and its dictionary, and uexp is a units expression in that units model. If the `um:' prefix is omitted, then a default unit model shall apply if declared in the general context part of the schema specification. The specification `u=' indicates the attribute value is unitless. When the unit model is API-SI, then restriction to a unit represents a typical or preferred use, although another unit having the same canonical form may be used. A unit having a different canonical form shall not be used.
  • The value restriction is specified as `v=ref', where ref may refer to the note or to a table of reference values for the attribute. Reference values are dictionary-controlled values belonging to an enumerated set. A schema may declare a value to consist of reference values and defer actual definition of the reference values to other schemas that may use the attribute's object type. A schema may provide an actual table of reference values or a normative reference to them.
  • Notes: Numbered references to notes that immediately follow the table. Notes are free-format descriptions of semantics and other rules about the attribute and its relation to other attributes.
  • 9 - Notation: How to Refer to an Attribute

    The notation TYPE:LABEL is used to refer to an attribute in a schema, where TYPE is the object type and LABEL is the attribute label. TYPE may be omitted if understood from context. If the schema is not clear from the context of the referral, then the additional notation n/TYPE:ATTRIBUTE is used, where n is the schema code of the object type.

    10 - Dictionary Specification

    10.1 - Preliminary Part

    The preliminary part of the dictionary may include the following:

  • title page.
  • table of contents.
  • foreword.
  • introduction.
  • 10.2 - Normative Part

    The normative part of the dictionary may include the following:

  • context.
  • title.
  • scope.
  • normative references.
  • schema: a reference to the schema (schema code, schema name, schema edition) and dictionary specification within the schema for which the dictionary is applicable.
  • authority.
  • sanctioning organization.
  • document preparation/revision/review committees.
  • proprietary considerations.
  • revision and versioning policies.
  • edition.
  • edition level.
  • summary of this and recent editions.
  • document status (draft or final).
  • definitions.
  • terminology.
  • normative references to other defining documents.
  • description of the reference value tables.
  • reference value tables.
  • title which identifies the attribute restricted to the reference values.
  • reference value column.
  • description column.
  • other columns as required by the schema.
  • 10.3 - Supplementary Part

    The supplementary part of the dictionary may include the following:

  • informative appendices.
  • footnotes.