Data Types - Abstract Specification

Generally these data types are used as the type of a RIM attribute in the presence of other models that may express further constraints on the domain values of these types. In such cases, there MAY be one single model which is regarded as the primary Constraining Model.

If the constraining model labels the attribute as Mandatory, the instance SHALL contain a valid data value that conforms to all the constraints stated in this specification and any additional constraints on the value domain stated in the model. In cases where the attribute is not mandatory, if the instance does not meet the constraints specified in the Constraining Model, the instance SHALL have some form of nullFlavor, though other information may still be provided.

The constraining model may apply a cardinality to an attribute. A cardinality consists of a minimum value, specified as a whole number, and a maximum value, specified as a whole number or "*". The cardinality is usually presented as [minimum value]..[maximum value], e.g. 0..1 or [1..*]. The meaning of the cardinality differs between collection based attributes and other attributes.

For attributes with a collection type (COLL and its specializations), the cardinality specifies how many items may be in the collection. A cardinality maximum value of * means that there is no limit to the number of items in the collection. (Note that this does not imply that applications are required to handle infinitely large collections of data, but the specification itself places no limit on the size of the collection). The minimum value specifies how many items must be in the collection. Note that in the case of a mandatory collection, the collection SHALL NOT contain any null items.

For other attributes, the only cardinalities that may be applied are 0..0, 0..1, and 1..1. Cardinality of 0 means that the attribute is not to be represented in the instance, and has an implicit nullFlavor of NI. Cardinality of 1 means that the attribute has a value, though the value may be a nullFlavor unless the attribute is also mandatory.

A mandatory attribute SHALL have a minimum cardinality of 1 or more.

If an application receives or parses an instance that does not conform to these rules, the receiver MAY reject the instance in whatever fashion it deems appropriate but it is not required to by this specification. Note that other specifications that describe how Constraining Models are constructed and applied MAY make additional rules concerning application behaviour.

Any specification that describes a model other than a primary constraining model (such as templates) MUST also describe how it affects the conformance behavior of downstream models. For further information, see in the "Core Principles of V3 Models" specification under "CIM" ([../coreprinciples/v3modelcoreprinciples.htm#coreP_Types_of_HL7_V3_Models-Static-CIM])

Every data type is declared in a form that begins with the keyword type. For example, the following is the header of a declaration for the data type Boolean which has the short name BL and specializes the data type ANY.

type Boolean alias BL specializes ANY
   values(true, false)
{
     BL  not;
     BL  and(BL x);
     BL  or(BL x);
     BL  xor(BL x);
     BL  implies(BL x);
};

The Boolean data type declaration also contains a values clause that declares the Boolean's complete set of values (its extension) as named entities. These named values are also valid character string literals. None of the other data types defined in this specification has a finite value set, which is why the values clause is unique to the Boolean.

The block in curly braces following the header contains declarations of the semantic properties that hold for every value of the data type. A semicolon terminates each property declaration; and another semicolon after the closing curly brace terminates the data type declaration.

A property declaration specifies from left to right (1) the data type of the property's value domain, (2) the property name, and (3) an optional argument list. The argument list of a property is enclosed in parentheses containing a sequence of argument declarations. Each argument is declared by the data type name and argument name. Semantic properties without arguments do not use an empty argument list.

The specializes clause implies (a) inheritance of properties from the genus to the species, and (b) substitutability of values of the species type for variables of the genus type. Specialization can include the definition of additional properties and the specification of constraints on inherited properties for the specialized type.

An example for inheritance: CD has the constraint that every nonNull CD must have a code. Because CS specializes CD, every CS must also have a code if it is nonNull, even though this constraint is not made explicit in the definition of CS itself. Note that a type can be declared to specialize a flavor rather than a type. This means that the type inherits from the base type that the flavor constrains, and in addition is subject to the constraints defined for the flavor.

An example for substitutability: A property is declared as of data type ED. Because ST specializes ED, then a value of such property MAY be of type ST. In other words, substitutability is the same as subsumption of all values of type ST being also values of type ED.

It is generally agreed that inheritance should not retract properties defined for the genus. However, because a child type may constrain the properties of a parent type, it is possible for a child to constrain a property to the null value without retracting the property.

The type declaration may be qualified by the keyword abstract, protected,, or private. An abstract type is a type where no non-exceptional value can be of this type: a proper value MUST belong to a concrete specialization of the abstract type. A protected type is a type that is used inside this specification but no property outside this specification should be declared of a protected type. A private type is an internal "helper" abstraction, defined only for the purpose of defining some aspect of the semantics of data types but that is not used even as the type of another protected or public type's property.¹

The declaration of semantic properties, their names, data types, and arguments provide only clues as to what the new data type might be about. The true definition lies in the invariant statements. Invariant statements are logical statements that are true at all times.

Throughout this specification, invariant statements are provided in a formal syntax but are also written in plain English. The advantage of the formal syntax is that it can be interpreted unambiguously, and that it is strongly typed. The advantage of plain English statements is that they are more understandable, especially to those untrained in reading formal languages.

The formal syntax sharpens the decisiveness of this specification. In some cases, however, the full semantics of a type are beyond what can be fully expressed in such invariant statements. The combination of both plain and formal language makes this specification more clear.

Invariant statements are formed using the invariant keyword that declares one or more variables in the form of an argument list of a property. The invariant statement can contain a where clause that constrains the arguments for the invariant body. The invariant body is enclosed in curly braces. It contains a list of assertions that must all be true.

invariant(BL x)
      where x.nonNull {
   x.and(true).equal(x);
};

The semantics of the invariant statement is a logic predicate with a universal quantifier ("for all").

The above invariant statement can be read in English as "For all Boolean values x, where x is non-NULL it holds that x AND true equals x." All properties should be named such that one can read the assertions like English sentences by substituting appropriate english words for the syntactical elements such as dot notation for property access. Note that some familiarity with reverse polish notation is useful in this regard.

The argument list of an invariant statement need not be specified if no such argument is needed.

invariant {
   true.not.equal(false);
   false.not.equal(true);
};

invariant(SET<T> x, y)
      where x.nonNull {
   x.subset(y).equal(
      forall(T element) where x.contains(element) {
         y.contains(element);
         });
};

invariant(SET x, y)
      where x.nonNull {
   x.intersects(y).equal(
      exists(T e) {
         x.contains(e);
         y.contains(e);
         });
};

This specification defines certain allowable conversions between data types. For example, there are a pair of conversions between the Character String (ST) and Encode Data (ED). This means that if a one expects an ED value but actually encounters an ST value instead, one can convert the ST value into an ED.

Three kinds of type conversions are defined: promotion, demotion, and character string literals. Type conversions can be implicit or explicit. Implicit type conversion occurs when a certain type is expected (e.g. as an argument to a statement) but a different type is actually provided. If the type provided has a conversion to the type expected the conversion should be performed implicitly.

NOTE: Implementation Technology Specifications must specify how implicit type conversions are supported. Some technologies support it directly, while others do not; in any case, processing rules can be defined that specify how these conversions are realized.

An explicit conversion can be specified in an assertion expression using the converted-to type name in parenthesis before the converted value. For example the following is an explicit type conversion from ED to ST in the where clause of an invariant statement.

invariant(ED x)
   where ((ST)x).nonNull { ... };

The type conversion has lower order of precedence than the property resolution period. Thus "(T)a.b " converts the value of the property b of variable a to data type T while "((T)a).b " converts the value of variable a to T and then references property b of that converted value.

Implicit type conversions in the assertion expressions are performed where possible. If a property's formal argument is declared of data type T, but the expression used as an actual argument is of type U, and if U does not extend T, and if U defines a conversion to T, that conversion from T to U takes effect.

type Interval alias IVL {
   ...
   demotion  QTY;
   ...
};

type Quantity alias QTY {
   ...
   promotion  IVL;
   ...
};

type Interval alias IVL {
   ...
   promotion  IVL (QTY x);
   ...
};

A literal is a character string representation of a data value. Literals are defined for many types. A literal is a type conversion from and to a Character String (ST) with a specially defined syntax.

Not every conversion from and to an ST is a literal conversion, however. A literal for a data type should be able to represent the entire value set of a data type whereas any other conversion to and from ST may only map a smaller subset of the converted data type.

The purpose of having literals is so that one can write down values in a short, human-readable form. For example, literals for the types integer number (INT) and real number (REAL) are strings of sign, digits, possibly a decimal point, etc. The more important interval types (IVL<REAL>, IVL<PQ>, IVL<TS>) have literal representations that allow one to use, e.g., "<5" to mean "less than 5", which is much more readable than a fully structured form of the interval. For some of the more advanced data types such as intervals, general timing specification, and parametric probability distribution, we expect that the literal form may be the only form seen for representing these values until users have become used to the underlying conceptualizations.

Each literal conversion has its own syntax (grammar), often aligned with what people find intuitive. This syntax may therefore not be the most obvious from a computing perspective.

NOTE: Character string based Implementable Technology Specifications (ITS) of these abstract data types may or may not choose the literals defined here as their representations for these data types. We expect that the XML ITS will use some but not all of the literals defined here. The different grammars of literals are not meant to be combined into one overall HL7 value expression grammar. Although attempts have been made to resolve potential ambiguities between the literals of different types where they would be harmful, some of these ambiguities still remain. For example "1.2" can be a valid literal for both Object Identifier (OID) and a Real Number.

type IntegerNumber alias INT {
   ...
   literal  ST;
   ...
};

type CardinalNumber alias CARD {
   BL       isZero;
   BL       equal(ANY x);
   CARD     successor;
   CARD     plus(CARD x);
   CARD     timesTen;
   literal  ST;
};

CARD.literal ST {
   CARD : CARD digit  { $.equal($1.timesTen.plus($2); }
        | digit       { $.equal($1); };

   CARD digit : "0"   { $.isZero; }
              | "1"   { $.equal(0.successor); }
              | "2"   { $.equal(1.successor); }
   ...
              | "8"   { $.equal(7.successor); }
              | "9"   { $.equal(8.successor); }
};

CARD : CARD digit
     | digit;

CARD digit : "0"
           | "1"
           | "2"
           | ...
           | "8"
           | "9";

CARD : CARD digit  { $.equal($1.timesTen.plus($2); }
     | digit       { $.equal($1); };

Generic data types are incomplete type definitions. This incompleteness is signified by one or more parameters to the type definition, which stand for other types, using the keyword template. Using parameters, a generic type might declare semantic properties that are not fully specified. For example, the generic data type Interval is declared with a parameter T that can stand for any Quantity data type (QTY). The properties low and high are declared as being of type T.

template<QTY T>
type Interval<T> alias IVL<T> {
   T  low;
   T  high;
};

Instantiating a generic type means completing its definition. For example, to instantiate an Interval, one SHALL specify of what base data type the interval should be. This is done by binding the parameter T to a specific data type. To instantiate an Interval of Integer numbers, one would bind the parameter T to the type Integer. Thus, the incomplete data type Interval is completed to the data type Interval of Integer.

For example, the following type definition for MyType declares a property named "multiplicity" that is an interval of the integer number data type used in the above examples.

type MyType alias MT {
   IVL<INT>  multiplicity;
};

A type parameter MAY have a default type associated with it. This default type is implied if no other parameter is bound when the type is associated. In the following example, a default parameter type has been used to specify exactly the same outcome as the previous example.

template<QTY T = INT>
type Interval<T> alias IVL<T> {
   T  low;
   T  high;
};

type MyType alias MT {
   IVL       multiplicity;
};

Default types for parameters requires care on the part of the users, and this technique is used sparingly in this specification.

Generics SHALL have types specified for each parameter prior to being instantiated. The types MAY be supplied in this specification, in any dependent specification, or even at run-time: that is, an ITS may allow the use of a generic type that leaves the parameter type unspecified until it is used.

template<ANY T>
type GenericTypeExtensionName specializes T {
   ...
};

invariant (INT x, INT y, PPD<INT> z) 
    where x.isOne.and(y.isOne).and(((INT) z).isOne).and(z.standardDeviation.nonNull) {
  x.equal(y);
  x.equal(z).isNull; 
};

Data type flavors are named constraints on the existing data types. The flavors do not introduce any new semantics to the data type, but constrain an existing data type for a particular purpose. Flavors MAY NOT add new properties, or set default values for properties; the value of properties can be fixed, but not defaulted.

Flavors MAY be used as types in other models, for instance in the RIM, and in RIM-derived models, when attributes are assigned a type that is a flavor. However flavors are not true types; when used in this fashion, they designate that the type of the attribute is the type from which the flavor is derived, with the constraints indicated in the flavor definition applied. For an instance of the data value assigned to the attribute, the type property is always that of the underlying type.

Flavors MAY constrain other flavors. When a flavor constrains another flavor, the flavor adds new constraints to those already specified in the other flavor.

Flavors are limited in this fashion so that a single implementation based on this specification will always be able to process all instances, but local implementations may describe a number of different constraint patterns on the data types defined in this specification.⁸

In the formal data type definition language, flavors follow this pattern:

flavor LongDescriptiveName alias ShortName constrains BaseTypeOrFlavor;

The definition of a flavor cannot introduce any new semantics, only define a long and short name, and the type or flavor that this flavor constrains. By convention, the short name has the form Type.shortName, such as TS.Time, but some flavors have other names due to backwards compatibility constraints. Once the flavor is defined it is usually followed by one or more invariants that specify the constraints associated with the flavor.

In rare cases, the constraints cannot be even partially expressed using the data type definition language, but it is still useful to define the flavor. In such cases, the flavor will not have any associated invariant statements. An example of this case would be further constraints on the narrative text described in the CDA specification ([http://www.hl7.org/v3ballot/html/infrastructure/cda/cda.htm]).

Representational Properties (§ B ) documents the property flavorId. When this representational property is used in association with one of the flavors documented here, it contains the value of the flavor name.

Additional flavors may be defined beyond those defined in this specification. The rules concerning definition, naming, and registration may be found in the Refinement, Constraint and Localization Specification ([http://www.hl7.org/v3ballot/html/infrastructure/conformance/conformance.htm]).

Some invariants make reference to concepts defined in a concept domain. The syntax for this reference is [CodeSystemName].[code] where [CodeSystemName] is the name of one of the code systems presented in this specification and [code] is the code of one of the concepts defined in that domain.

invariant(ANY x) {
   x.isNull.equal(x.nullFlavor.implies(NullFlavor.NI));
};

This invariant specifies that when a data type is null, its nullFlavor property implies the NullFlavor concept NI, which is identified by the Concept Reference NullFlavor.NI.

Definition:      The data type of the value.

Every proper data value implicitly carries information about its own data type.

invariant(ANY x) where x.nonNull {
   x.dataType.nonNull;
};

Note that the type of a flavor is always the underlying type. For instance, the type of a ED.IMAGE is always ED. The kind of flavor will be identified in the flavorId property. See Representational Properties (§ B ) for further information.

An exceptional value may not have a type specified by its context of use, either in the applicable models or the instance itself. In these cases, the datatype will default to ANY. Data values with a nullFlavor that implies INV SHALL have a known type that is not ANY.

invariant(ANY x) 
  where x.nullFlavor.implies("INV") {
   x.dataType.nonNull;
};

Definition:      An indicator of a data value's exceptional status, sometimes also denoting the manner and rationale for that status.

A data type MAY have an exceptional value (NULL-value, or just "null") rather than a proper value as described by this specification, either because the information does not exist, is not known or available, or cannot be expressed in the allowed value domain. In this case, the nullFlavor expresses in what way and why proper information is missing.

Null values are improper values that do not conform to the proper or expected value domain as described by this specification. This specification makes many rules concerning the relationship between the nullFlavor property and other properties, and these rules SHALL always be true. Both nonNull and null values SHALL always be valid according to the rules expressed in this specification.

Null values are also known as exceptional values. This is to denote that the information contained in the value is an exception to the expected value domain that applies to the type. The information may either be missing or partially present, or even completely present but not valid with respect to the constraints imposed by the Constraining Model (see Constraining Model (§ 1.8.1 )).

NOTE: This property is named nullFlavor because of the similarities between the concept of null value and the concept and behaviour of null in implementation technologies, particularly SQL and OCL. As in SQL and OCL, the result of a comparison operation between a null value and some other value is always null. In this sense, null values propagate through operations. However there are some notable differences between these concepts. Most notably, in most implementation technologies, a null instance has no further information associated with it (some variation of the concept of a null pointer). This is not true of the HL7 concept of null, where any of the properties of a null value might not be null. In OCL, null is an instance of OclVoid which is a super type of all types. This is not true for null values in this specification where a null value is still a valid instance of a particular type. If a true null is encountered in an implementation environment, it is semantically equivalent to a null-value of NI, and all other properties not related to nullFlavor will also have nullFlavor NI.

The null concept provides a general framework for handling incomplete data which is often encountered in healthcare information collection, use and analysis. The nullFlavor property plays a special role in the conformance framework. See "Conformance" in Core Principles of V3 Models [../coreprinciples/v3modelcoreprinciples.htm#coreP_V3_Conformance] for further information.

The null flavors are a general domain extension of all normal data type domains ("domain" in this sense means the set of all possible values for the data type, not "domain" in the more restricted sense used for coded data types). So this is true not only for coded data types with specified vocabulary domains, but for non-coded value domains as well, e.g. integers, temporal intervals, infectious disease cases, etc.

Note that while all these nullFlavors are considered to be exceptional values - a proper value is not known, under some circumstances the nullFlavor itself may be semantically useful. For instance, while the value PINF may represent an actual unknown value, it can be used as the upper limit of an interval. Similarly, the value QS represents an unknown amount but may be converted to a real amount during the actual dispensing of a formulation.

As a general domain extension of all normal data types, the null flavors also extend the literal form of those data types that have a literal form. In any literal form, the literal NullFlavor.X signals that the data type has the assigned nullFlavor, where X is the code, such as NA.

Note that the nullFlavor property isNull is reverse to that of the data type itself. If the data type is not null, then the nullFlavor property itself will be null. If the data type is null, then the nullFlavor is not null - it will specify an actual nullFlavor that provides more detail as to in what way or why no proper value is supplied.

invariant(ANY x) {
   x.nullFlavor.isNull.equal(x.nonNull);
};

The general implication of this is that in a CD or descendant (usually CS), when the code for a nullFlavor is carried in the code/codeSystem (code = "NI" and codeSystem = "2.16.840.1.113883.5.1008"), the CD itself is not null. The CD is only null when its nullFlavor carries this code.

When performing operations upon null values, the semantic meaning of the nullFlavor SHALL be considered. This is particularly important for equality. The only case where non-proper (NULL) values may be equal is where both values have a nullFlavor of NA. In most other cases, the outcome of comparing NULL values is also null. However, there are exceptions based on the semantic meaning of nullFlavor. For instance, although direct comparison of two values with nullFlavor PINF is always null (NI), two intervals with the equal low bounds and high bounds of PINF will return true, since they specify the same set. Similarly, comparison of NINF and PINF is always False.

The "actual value" refers to the value of the information itself, rather than the information as represented in the type itself. These two may diverge when the information provided is incomplete, such as when an expression is provided. The null flavor "other" is used whenever the actual value is not in the required value domain: this may occur, for example, when the value exceeds some constraints that are defined in too restrictive a manner

For example, if the value for age is 100 yrs, but the constraining model specifies that the age must be less than 100 years, the age may still be specified, provided that the model does not make the attribute mandatory.

<value nullFlavor="OTH" value="120" unit="yr"/>

Some of the null flavors are not generally applicable to all data types. The nullFlavors NINF and PINF SHALL only be associated with QTY types other than MO and RTO. The nullFlavors QS, and TRC SHALL only be used with PQ. The nullFlavor UNC SHALL only be used with any type that has an originalText, and when UNC is used the originalText property SHALL be populated. The nullFlavor DER SHALL only be used with the EXPR type, and an expression SHALL be provided.

invariant(ANY x) {
  x.nullFlavor.implies(NullFlavor.PINF).implies(x.dataType.implies(QTY));
  x.nullFlavor.implies(NullFlavor.NINF).implies(x.dataType.implies(QTY));
  x.nullFlavor.implies(NullFlavor.QS).implies(x.dataType.implies(QTY));
  x.nullFlavor.implies(NullFlavor.TRC).implies(x.dataType.implies(QTY));

  /* if whatever type x is doesn't have an originalText property, 
     the invariant will be null (not true) */
  x.nullFlavor.equals(UNC).implies(((x.dataType)x).originalText.nonNull);

  x.nullFlavor.equals(DER).implies(x.dataType.implies(EXPR<QTY>)
    .and((EXPR<QTY>) x).expression.nonNull);
};

Note: the two nullFlavors INV and OTH draw a distinction between the actual value and the vlalue as represented in the instance. Some of the datatypes may be used to provide a representation of the value which requires subsequent transformation to generate the real value. For instance, an expression may be provided which will generate an actual value that is in the required value domain of the instance.

NOTE: NULL-flavors are applicable to any property of a data value or a higher-level object attribute. Where the null flavor is determited to be not significant by the core HL7 infrastrcture committees, ITS are not required to represent them. If nothing else is noted in this specification, ITS need not represent general NULL-flavors for data-value properties. In addition, there is a difference between semantic properties and representational "components" of data values. An ITS SHOULD only represent those components that are needed to infer the semantic properties. The null-flavor predicates nonNull, isNull, notApplicable, unknown, and other can all be inferred from the nullFlavor property.

Some of these null flavors are associated with named properties that can be used as simple predicates for all data values. This does not change the semantics of the property; it is done to simplify the formulation of invariants in the remainder of this specification.

Definition:      A predicate indicating that that a property has a value, i.e. is a non-null ("non-exceptional") value of the data type.

invariant(ANY x) {
   x.nonNull.equal(x.isNull.not);
};

When a property (i.e. RIM attribute, or message field) is labeled mandatory, and the container is not null itself, then any value assigned to the property SHALL be nonNull.

Definition:      A predicate indicating that that a value is an exceptional value, or a null-value. A null value means that the information does not exist, is not available, or cannot be expressed in the data type's normal value set.

Every data element has either a proper value or it is considered NULL. If (and only if) it is NULL, the nullFlavor provides more detail as to in what way or why no proper value is supplied.

invariant(ANY x) {
   x.isNull.equal(x.nullFlavor.implies(NullFlavor.NI));
};

Definition:      A predicate indicating that this exceptional value is of nullFlavor not-applicable (NA), i.e., that a proper value is not meaningful in the given context.

invariant(ANY x) {
   x.notApplicable.equal(x.nullFlavor.implies(NullFlavor.NA));
};

Definition:      A predicate indicating that this exceptional value is of nullFlavor unknown (UNK).

invariant(ANY x) {
   x.unknown.equal(x.nullFlavor.implies(NullFlavor.UNK));
};

Definition:      A predicate indicating that this exceptional value is of nullFlavor other (OTH), i.e., that the required value domain does not contain the appropriate value.

invariant(ANY x) {
   x.other.equal(x.nullFlavor.implies(NullFlavor.OTH));
};

Definition:      A reflexive, symmetric, and transitive relation between any two data values indicating that the two values are the same.

invariant(ANY x, y, z)
      where x.nonNull.and(y.nonNull).and(z.nonNull) {
   x.equal(x);                                         /* reflexivity */
   x.equal(y).equal(y.equal(x));                       /* symmetry */
   x.equal(y).and(y.equal(z)).implies(x.equal(z));      /* transitivity */
};

How equality is determined must be defined for each data type, and care must be taken when implementing equals in a polymorphic environment. There is a tension between what is logical and desired, and the requirement for symmetry and transitivity. ⁹ These data types and the definitions of equals have been carefully constructed so that their definitions of equals are both symmetric and transitive.

Some of the definitions of equality exclude some of the properties of a data type from the equality test, where those properties are not essential to the meaning of the value. In addition, some interpretation of the semantics of the values may be required to determine the equality of two values. For example physical quantity () has the two semantic properties (1) a real number and (2) a coded unit of measure. The equality test, however, must account for the fact that, e.g., 1 meter equals 100 centimeters; independent equality of the two semantic properties is too strong a criterion for the equality test. Therefore, physical quantity must override the equality definition.

The requirement for understanding the meaning of the data applies to nullFlavors as well. Under certain circumstances the test for equality between two different values with different flavors of null may not be null. Consult nullFlavor for more information.

Definition:      Identity comparison is a reflexive, symmetric, and transitive relation between any two data values. Any values can be identical, whether or not they are null or contain property with null values. The identity comparison always returns true or false. The result is never null.

The identity relationship is defined to assist in the definition of uniqueness constraints on DSETs. The identity relationship SHOULD NOT otherwise be used as it has no other use, and is therefore given a protected status to indicate that it should not be used outside this specification.

invariant(ANY x, y, z) {
   x.identical(x);                                              /* reflexivity */
   x.identical(y).equal(y.identical(x));                        /* symmetry */
   x.identical(y).and(y.identical(z)).implies(x.identical(z));  /* transitivity */
};

How identity is determined is the same for every data type except BL. If all the properties of two values are identical, the values are identical. For BL, the two values are identical if they have the same nullFlavor or if they are both true or both false.¹⁰

Definition:      The alias of the data type.

invariant(DataType x)
      where x.nonNull {
   x.shortName.nonNull;
};

Definition:      The full name of the data type.

Two nonNull data types are equal if they are the same type.

invariant(DataType x, y)
      where x.nonNull.and(y.nonNull) {
   x.equal(y).equal(x.shortName.equal(y.shortName));
};

Definition:      A relation that indicates that a data type has the same type or is a specialization of the argument type.

Definition:      A relation that indicates whether two types have the same equality criteria

A data type is comparable to another data type if they both have the same equality criteria. For instance, has the same equality criteria as , so is comparable to . Note that the fact that two data types can be compared does not mean that all instances of the data types may be compared - for instance, it is not possible to compare the PQ values 3yr and 5m.

Definition:      The opposite value. Negation of a BL turns true into false and false into true and is NULL for NULL values.

invariant(BL x) {
   true.not.equal(false);
   false.not.equal(true);
   x.isNull.equal(x.not.isNull);
};

Definition:      Conjunction between a value and another value indicates that both values are true. Conjunction is associative and commutative, with true as a neutral element. False AND any Boolean value is false. These rules hold even if one or both of the operands are NULL. If both operands for AND are NULL, the result is NULL.

invariant(BL x, y) {
   x.and(true).equal(x);
   x.and(false).equal(false);
   x.isNull.implies(x.and(y).isNull);
};

Definition:      A parametric property indicating that the value or the argument is true, or both are true. The disjunction x OR y is false if and only if x is false and y is false.

invariant(BL x, y) {
   x.or(y).equal(x.not.and(y.not).not);
};

Definition:      A parametric property indicating that either the value or the argument is true, but not both.

invariant(BL x, y) {
   x.xor(y).equal(x.or(y).and(x.and(y).not));
};

Two non null BL are equal if the have the same value.

invariant(BL x, y)
      where x.nonNull.and(y.nonNull) {
   x.equal(y).equal(x.equal(true).and(y.equal(true).or(x.equal(false).and(y.equal(false)))));
};

Definition:      A parametric property indicating that the argument is true when the value is true, supporting rules of the form IF condition THEN conclusion

Logically, the implication is defined as the disjunction of the negated condition and the conclusion, meaning that when the condition is true the conclusion must be true to make the overall statement true. The logical implication is important to make invariant statements.

invariant(BL condition, conclusion) {
   condition.implies(conclusion).equal(
      condition.not.or(conclusion));
};

The implication is not reversible and does not specify whether the condition is true when the condition is false (ex falso quodlibet lat. “from false follows anything”).

The literal form of the Boolean is determined by the named values specified in the values clause, i.e., true and false.

Definition:      An indicator that the COLL has no elements. The return value may be null (when the collection itself is null, whether the collection is empty is not known).

Definition:      An indicator that the COLL contains at least one item. The return value may be null (when the collection itself is null, whether the collection is empty is not known).

Definition:      The number of elements in the COLL. The return value may be null (when the collection itself is null, the number of items in the collection is not known).

Definition:      An indicator that the COLL contains an item with the given item value using the equals property. If item is null, the return value will be null.

Definition:      The number of elements in the bag. NULL elements are counted as bag elements.

invariant(BAG<T> bag, INT zero)
      where bag.nonNull.and(zero.isZero) {
   bag.isEmpty.equal(bag.count.isZero);
   bag.notEmpty.equal(bag.count.greaterThan(zero));
};

Definition:      The number of items in this bag with the given item value.

This is the primitive property of a BAG, on which all other properties are defined.

invariant(BAG<T> bag, T item)
      where bag.nonNull {
   bag.count(item).nonNegative;
   bag.isEmpty.implies(bag.count(item).isZero);
};

Definition:      True if the bag contains an item with the given item value.

invariant(BAG<T> bag, T item)
      where bag.nonNull {
   bag.contains(item).equal(bag.count(item).isNegative.not);
};

Definition:      A predicate indicating that this BAG has no elements (negation of the notEmpty predicate. The empty BAG is a proper value, not an exceptional (NULL) value.

invariant(BAG<T> bag)
      where bag.nonNull {
   bag.isEmpty.equal(notEmpty.not);
};

Definition:      A predicate indicating that this BAG contains at least one item. The item MAY be null.

invariant(BAG<T> bag)
      where bag.nonNull {
   bag.notEmpty.equal(exists(T item) {
      bag.contains(item);
      });
};

Definition:      A BAG that contains all items of the operand BAGs.

invariant(BAG<T> x, y, z)
      where x.nonNull.and(y.nonNull) {
   x.plus(y).equal(z).equal(
      forall(T e)
            where e.nonNull {
         z.contains(e).equal(x.contains(e)
                      .or(y.contains(e)));
         });
};

Definition:      A BAG that contains all items of this BAG (minuend) diminished by the items in the other BAG (subtrahend). BAGs cannot carry deficits: When the subtrahend contains more items of one value than the minuend, the difference contains zero items of that value.

invariant(BAG<T> x, y, z)
      where x.nonNull.and(y.nonNull) {
   x.minus(y).equal(z).equal(
      forall(T e)
            where e.nonNull {
               exists(INT n)
                  where n.equal(x.count(e).minus(y.count(e))) {
         n.nonNegative.equal(z.count(e));
         n.isNegative.equal(z.count(e).isZero);
         };
      });
};

When the element type T has a literal form, the bag of T elements has a literal form, wherein the elements of the set are enumerated within curly braces and separated by semicolon characters.

BAG<T>.literal ST.SIMPLE {
   BAG<T>          : "{" elements "}"   { $.equal($2); };
   BAG<T> elements : elements ";" T     { $.except($2).equal($1); }
                  | T                   { $.contains($1);
                                          $.except($1).isEmpty; };
};

NOTE: This literal form for bags is only practical for relatively small bags; this does not mean, however, that all bag are relatively small enumerations of elements.

NOTE: A character-based ITS SHOULD choose a different literal form for bags if the Implementation Technology has a more native literal form for such collections.

A data value of type T can be promoted into a trivial BAG of type T with that data value as its only item.

invariant(T x) {
   ((BAG<T>)x).count.equal(1);
}

invariant(T x) where x.isNull {
   ((BAG<T>)x).count(x).isNull;
}

invariant(T x) where x.nonNull {
   ((BAG<T>)x).count(x).equal(1);
   
   forall(T y) where y.nonNull {
      ((BAG<T>)x).count(y).isZero.not
                 .implies(x.equal(y)) };
}

invariant(T x) where x.isNull {
   ((BAG<T>)x).count(x).unknown;
};

A discrete set of items can be promoted into a BAG that contains the same items. No items are lost during the promotion.

invariant(DSET<T> x) where x.nonNull {
   ((BAG<T>)x).count.equal(x.count);
};

invariant(DSET<T> x, T y) where x.nonNull.and(y.nonNull) {
   ((BAG<T>)x).contains(y).equal(x.contains(y));
};

Two bags are equal if and only if they are both empty, or if they both contain the same items.

It is not necessary that the two BAGs have the same type for parameter T; as long as the two bags have parameter types that are comparable (for instance, CD and CV), the bags can be equal.

invariant(BAG<T> x, BAG<U> y)
      where x.nonNull.and(y.nonNull).and(T.datatype.compares(U.datatype)) {
   x.equal(y).equal((forall(T e) {
      x.count(e).equal(y.count(e));
    }).and(forall(U e) {
      x.count(e).equal(y.count(e));
    }));
};

Definition:      The first item in this sequence.

Definition:      The sequence following the first item in this sequence.

Definition:      A predicate that is true if this sequence contains no items.

An empty sequence is a proper sequence, not an exceptional (null) value.

invariant(LIST<T> x)
      where x.isEmpty {
   x.length.isZero;
   x.head.isNull;
   x.tail.isEmpty;
};

In an empty sequence, the length is zero, the tail is empty, and the head is null. Note that both head and tail being NULL does not mean that the sequence is empty; while this is a necessary condition of an empty sequence, it is not sufficient for determining an empty list, since a sequence may contain NULL-values as items. Therefore this condition can mean that the sequence has only a head item that happens to be NULL.

Definition:      A predicate that is true if this sequence contains at least one element. Negation of isEmpty.

invariant(LIST<T> x)
      where x.nonNull {
   x.notEmpty.equal(x.isEmpty.not);
};

Definition:      The item at the given sequential position (index) in the sequence. The index zero refers to the first element (head) of the sequence.

invariant(LIST<T> list; INT index)
      where list.nonNull.and(index.nonNegative) {
   list.isEmpty.implies(list.item(index).isNull);
   list.notEmpty.and(index.isZero)
       .implies(list.item(index).equal(list.head));
   list.notEmpty.and(index.nonZero)
       .implies(list.item(index).equal(
          list.tail.item(index.predecessor)));
};

Definition:      A predicate that is true if this sequence contains the given item value.

invariant(LIST<T> list; T item)
      where list.nonNull {
   list.isEmpty.implies(list.contains(item).not);
   
   list.nonEmpty.and(item.nonNull).implies(list.contains(item).equal(
        list.head.equal(item).or(list.tail.contains(item))));
		
   list.notEmpty.and(item.isNull).implies(list.contains(item).equal(
        list.head.isNull.or(list.tail.contains(item))));
};

Definition:      The number of elements in the sequence. NULL elements are counted as sequence elements.

invariant(LIST<T> list)
      where list.nonNull {
   list.isEmpty.equal(list.length.isZero);
   list.notEmpty.equal(list.length.equal(list.tail.length.successor));
};

Definition:      The number of elements in the list.

This property is defined for consistency of definitions of collection types. The count of the number of elements in a discrete set always matches the length of the list.

invariant(LIST<T> list) where list.nonNull {
   list.count.equal(list.length);
};

Definition:      A contiguous subset of the list containing the items found in the list from index start to end, inclusively.

invariant(LIST<T> x, INT start, end)
   where 
     x.nonNull.and(
	 start.greaterOrEqual(0)).and(
	 start.lessThan(x.length)).and(
	 end.greaterOrEqual(0)).and(
	 end.lessThan(x.length)).and(
	 start.lessOrEqual(end)) {
   x.subList(start, end).length.equal(end.minus(start).sucessor);
   forall(INT i) where i.greaterOrEqual(0).and(i.lessThen(end.minus(start))) {
     x.subList(start, end).item(i).equal(x.item(start.plus(i)));
   }
};

The list starts at item 0. If the bounds are less than 0 or greater than or equal to the length of the list, or if end is less than start, then the result of the operation is undefined (i.e. null).

Definition:      A contiguous subset of the list containing the items found in the list from index start to the end of the list, inclusively.

invariant(LIST<T> x, INT start)
   where 
     x.nonNull.and(
	 start.greaterOrEqual(0)).and(
	 start.lessThan(x.length)).and(
	 end.greaterOrEqual(0)) {
   x.subList(start).length.equal(x.length.minus(start));
   forall(INT i) where i.greaterOrEqual(0) {
     x.subList(start).item(i).equal(x.item(start.plus(i)));
   }
};

The list starts at item 0. If the bounds are less than 0 or greater than or equal to the length of the list, then the result of the operation is undefined.

Two lists are equal if and only if they are both empty, or if both their head and their tail are equal.

It is not necessary that the two LISTs have the same type for parameter T; as long as the two lists have parameter types that are comparable (for instance, CD and CV), the lists can be equal.

invariant(LIST<T> x, LIST<U> y)
      where x.nonNull.and(y.nonNull).and(T.datatype.compares(U.datatype)) {
   x.isEmpty.and(y.isEmpty).implies(x.equal(y));
   
   (x.notEmpty.and(y.isEmpty)).or(x.isEmpty.and(y.notEmpty)).implies(x.equal(y).not);
   
   x.notEmpty.and(y.notEmpty).and(x.head.nonNull).implies(
      x.equal(y).equal(x.head.equal(y.head).and(x.tail.equal(y.tail))));
	  
   x.notEmpty.and(y.notEmpty).and(x.head.isNull).implies(
      x.equal(y).equal(y.head.isNull.and(x.tail.equal(y.tail))));
};

Note that when lists contain null items, it is usually not possible to determine whether the lists are equal, though it may be possible to determine that they are different. For example, a list containing an unknown value is not equal to a list containing another unknown value, nor are two lists holding values of PINF. However a list containing a value of NINF is not equal to a list holding a value of PINF.

When the element type T has a literal form, the sequence LIST has a literal form. List elements are enumerated, separated by semicolon, and enclosed in parentheses.

LIST<T>.literal ST.SIMPLE {
   LIST<T> : "(" elements ")"        { $.equal($2); }
           | "(" ")"                 { $.isEmpty; };
   LIST<T> elements
           : T ";" elements          { $.head.equal($1);
                                       $.tail.equal($3); }
           | T                       { $.head.equal($1);
                                       $.tail.isEmpty; };
};

NOTE: a character-based ITS SHOULD choose a different literal form for sequences if the Implementation Technology has a more native literal form for such collections.

A data value of type T can be promoted into a trivial sequence of T with that data value as its only item.

invariant(T x) {
   ((LIST<T>)x).head.equal(x);
   ((LIST<T>)x).tail.isEmpty;
};

A sequence (an ordered collection of items) can be demoted to a bag of items (no order). All items are preserved in the demotion.

invariant(LIST<T> x) where x.nonNull {
   ((BAG<T>)x).count.equal(x.count);
};

invariant(LIST<T> x, T y) where x.nonNull.and(y.nonNull) {
   ((BAG<T>)x).contains(y).equal(x.contains(y));
};

Definition:      The comparator used to define uniqueness and membership in the set.

The uniqueness in the set is a function of the comparator.

invariant(SET<T> x)
      where x.nonNull {
 forall(T a) where a.nonNull {
   forall(T b) where b.nonNull {
     /* if the comparator cannot compare a or b,
	    both cannot be in the Set */ 
	 x.contains(a).and(x.contains(b)).implies.
	    x.comparator.compare(a, b).nonNull;  
	   
     /* if both a and b are in the set, they must be different 
       (unless they are the are the same instance)*/ 
	 x.contains(a).and(x.contains(b)).implies(
	   a.identical(b).or(x.comparator.compare(a, b).not));
	 }
   }
};

Because of these constraints, considerable care must be taken in defining the comparator. In particular, the equals-based comparator SHALL always be used for types that are specializations of QTY. Note also that where a comparator could be defined that specifies nonNull outcomes for null values of T, sets MAY contain null values.

Implementable Static Models SHALL always fix the comparator - it must not be left to be decided at run-time.

Definition:      A relation of the set with a value, true if the given value is an element of the set.

This is the primitive semantic property of a set, based on which all other properties are defined. Contains is ascertained using the comparator for the SET, which MAY specify some different comparison than the equals property.

A set SHALL only contain distinct elements. Values for which the comparator is unable to differentiate cannot be elements of a set. For normal sets, based on CEQ, exceptional values (NULL-values) cannot be elements of a set.

invariant(SET<T> s, T m, n)
      where s.nonNull {
   s.contains(m).and(s.contains(n)).implies(s.comparator.compare(m,n).nonNull);
};

invariant(SET<T> s, T n)
      where s.nonNull.and(s.comparator.implies(CEQ)).and(n.isNull) {
   s.contains(n).not;
};

Definition:      The relation between a set and its subsets, where each element in the subset is also an element of the superset.

invariant(SET<T> superset, subset) 
      where superset.nonNull.and(subset.nonNull) {
         superset.contains(subset).equal(
      forall(T element) where subset.contains(element) {
         superset.contains(element);      
	     });
};

This implies that the empty set is a subset of every set including itself.

Definition:      A predicate indicating that this set has no elements; the negation of notEmpty. The empty set is a proper set value, not an exceptional (NULL) value.

invariant(SET<T> set)
      where set.nonNull {
   set.isEmpty.equal(notEmpty.not);
};

Definition:      A predicate indicating that this set contains elements.

invariant(SET<T> set)
      where set.nonNull {
   set.notEmpty.equal(exists(T element) {
      set.contains(element);
      });
};

Definition:      The number of distinct elements in the set.

invariant(SET<T> set)
      where set.nonNull {
   exists(T element) where set.contains(element) {
      set.cardinality.equal(set.except(element)
                     .cardinality.successor);
         };
};

The cardinality definition works for finite sets in this specification, but is not sufficient since it doesn't converge for uncountably infinite sets (REAL, PQ, etc.) and it doesn't terminate for infinite sets. The cardinality value is an example where it would be necessary to distinguish the cardinality ℵ₀ (aleph₀) of countably infinite sets (e.g., INT) from ℵ₁ (aleph₁), the cardinality of uncountable sets (e.g., REAL, PQ).

Definition:      A set for which each element is an element of at least one component set.

invariant(SET<T> x, y, z)
      where x.nonNull.and(y.nonNull).and(z.nonNull) {
   x.union(y).equal(z).equal(forall(T e) {
      z.contains(e).equal(x.contains(e).or(y.contains(e)));
      });
};

Definition:      A union of a set and an element.

invariant(SET<T> set, singletonset; T element)
      where set.nonNull.and(element.nonNull)
               .and(singletonset.cardinality.isOne)
               .and(singletonset.contains(element)) {
   set.union(element).equal(set.union(singleton));
};

Definition:      The set containing all elements of the subtracted set that are not elements of the subtracting set.

invariant(SET<T> x, y, z)
      where x.nonNull.and(y.nonNull).and(z.nonNull) {
   x.except(y).equal(z).equal(forall(T e) {
      z.contains(e).equal(x.contains(e).and(y.contains(e).not));
      });
};

Definition:      The set that contains all elements of this set except for the subtracting element value.

invariant(SET<T> x, z; T d)
      where x.nonNull.and(z.nonNull).and(d.nonNull) {
   x.except(d).equal(z).equal(forall(T e) {
      z.contains(e).equal(x.contains(e).and(d.equal(e).not));
      });
};

Definition:      The set containing all and only those elements that are contained in both of the operand sets.

invariant(SET<T> x, y, z)
      where x.nonNull.and(y.nonNull).and(z.nonNull) {
   x.intersection(y).equal(z).equal(forall(T e) {
      z.contains(e).equal(x.contains(e).and(y.contains(e)));
      });
};

Two nonNull SETs are equal if they have the same elements. It is not necessary that the two SETs have the same type for parameter T; as long as the two sets have parameter types that are comparable (for instance, CD and CV), the sets can be equal.

invariant(SET<T> x, SET<U> y)
      where x.nonNull.and(y.nonNull).and(T.datatype.compares(U.datatype)) {
   x.equal(y).equal((forall(T e) {
      x.contains(e).equal(y.contains(e));
    }).and(forall(U e) {
      x.contains(e).equal(y.contains(e));
    }));
};

Definition:      The data type of the comparator.

Every comparator implicitly carries information about its own data type.

invariant(COMP x) {
   x.dataType.nonNull;
};

Definition:      The result of comparing the two elements.

Like the equality relationship, comparison is a reflexive, symmetric, and transitive relationship between any two data values.

invariant(COMP<T> c, T x, y, z)
      where x.nonNull.and(y.nonNull).and(z.nonNull) {
   c.compare(x, x);                                                 /* reflexivity */
   c.compare(x, y).equal(c.compare(y, x));                          /* symmetry */
   c.compare(x, y).and(c.compare(y, z)).implies(c.compare(x, z));   /* transitivity */
};

Definition:      The value of the equality relationship between the two values.

invariant(CEQ<T> c, T x, y)
      where x.equal(y).nonNull {
   c.compare(x, y).equal(x.equal(y));
};

Definition:      The number of elements in the set.

This property is defined for consistency of definitions of collection types. The count of the number of elements in a discrete set always matches the cardinality of the set.

invariant(DSET<T> set) where set.nonNull {
   set.count.equal(set.cardinality);
};

When the element type T has a literal form, the discrete set of T elements has a literal form, wherein the elements of the set are enumerated within curly braces and separated by semicolon characters.

DSET<T>.literal ST.SIMPLE {
   DSET<T>          : "{" elements "}"   { $.equal($2); };
   DSET<T> elements : elements ";" T     { $.except($2).equal($1); }
                  | T                   { $.contains($1);
                                          $.except($1).isEmpty; };
};

NOTE: This literal form for sets is only practical for relatively small discrete sets; this does not mean, however, that all sets are relatively small enumerations of elements.

NOTE: A character-based ITS SHOULD choose a different literal form for discrete sets if the Implementation Technology has a more native literal form for such collections.

A data value of type T can be promoted into a trivial discrete set of T with that data value as its only element.

invariant(T x) where x.nonNull {
   ((DSET<T>)x).contains(x);
   ((DSET<T>)x).except(x).isEmpty;
};

invariant(T x) where x.isNull {
   ((DSET<T>)x).isNull;
};

The evaluation of equality for DSET is taken from the SET data type: Two nonNull SETs are equal if they have the same elements.

This means that values of the type DSET and any other kind of SET MAY be equal.

Definition:      The time interval during which the given information was, is, or is expected to be valid. The interval can be closed-- i.e. finite and defined—or open—i.e. infinite or undefined —on either side. The interval cannot be just a width, nor can the width be zero

invariant(HXIT<T> x) where x.nonNull {
  x.validTime.nonNull.implies(x.validTime.low.nonNull.or(x.validTime.high.nonNull));
  x.validTime.nonNull.implies(x.validTime.width.isZero.not);
};

Definition:      A predicate expressing a chronological order relation that is asymmetric and transitive, between this HXIT and another HXIT.

A HXIT comes before another in a sequence of history items (HIST) if the high boundary of the validTime is less or equal to the low boundary of the other interval.

invariant(HXIT<T> x, y) where x.validTime.nonNull.and(y.validTime.nonNull) {
  x.comesBefore(y).implies(x.validTime.high.nonNull);
  x.comesBefore(y).implies(y.validTime.low.nonNull);
  x.comesBefore(y).implies(x.validTime.high.lessOrEqual(y.validTime.low));
};

Definition:      The identifier of the ControlAct associated with setting the data type to its specified value.

By referencing a particular ControlAct, the property links to all of the information surrounding that ControlAct, such as who made the change, when it was made, why it was made, what system originated the change, etc.

Definition:      The item in the list whose validTime interval includes the current time.

Note that the current time is not necessarily the same time as the instant at which an instance is being processed. The relevant current time will be dictated by the context of operation.

There may be no current value, in which case the value of this operation is NULL.

Definition:      The item in the list whose IVL.LOW boundary (validity start time) is less than (i.e. before) or equal to that of any other history item in the list.

invariant(HIST x; HXIT<T> e)
      where x.contains(e) {
   x.earliest.validTime.low.lessOrEqual(e.validTime.low);
};

Definition:      The derived history that has the earliest item excluded.

invariant(HIST x)
      where x.nonNull {
   x.exceptEarliest.equal(x.except(x.earliest));
};

Definition:      The item in the list whose IVL.HIGH boundary (validity end time) is greater than (i.e. after) or equal to that of any other history item in the list.

invariant(HIST x; HXIT<T> e)
      where x.contains(e) {
   x.latest.validTime.high.greaterOrEqual(e.validTime.high);
};

Definition:      The derived history that has the latest item excluded.

invariant(HIST x)
      where x.nonNull {
   x.exceptLatest.equal(x.except(x.latest));
};

invariant(HIST x)
      where x.nonNull {
   x.notEmpty;
   ((T)x).equal(x.current);
};

A type conversion between an entire history HIST and a single history item HXIT. This conversion takes the current data from the history, if a current value exists.

The purpose of this conversion is to allow an information producer to produce a history of any value instead of sending just one value.¹² An information-consumer, who does not expect a history but a simple value, will convert the history to the current value. Note that the source system may only send a history of a value if the constraining models permits this.

The evaluation of equality for HIST is the same as the LIST data type. This means that values of the type HIST and LIST may be equal.

The evaluation of equality for BIN is the same as the LIST data type.

This means that values of the type BIN and LIST<BL> may be equal.

Definition:      The binary content of the ED

ED acts as a wrapper of binary content. Operations performed against the ED directly are mediated by the mediatype and, if so indicated by the mediatype, the character set. For example, two BIN values are equal if they have the same sequence of bits in their content. However the ED are only equal if they have the same sequence of logical items. For instance, if the media type is a kind of text, then the sequence of characters indicated by the character set and the binary content must be equal. Similarly, the length of an ED is the number of component parts as indicated by the mediatype. For application and image media types, the length of ED is the same as the length of the data. Note that operations may also be performed directly upon the binary content by using data.

invariant(ED x)
      where x.nonNull {
   x.data.nonNull;			
};

Although data SHALL be nonNull if the ED is not null, it need not be contained in-line in the instance; instead, the binary content, along with some other properties, MAY be defined by the reference property.

Definition:      The type of the encapsulated data.

The default mediaType is text/plain. The type of the encapsulated data may help identify a method to interpret or render the data.

mediaType is a mandatory property, i.e., every non-NULL instance of ED SHALL have a non-NULL mediaType property.

invariant(ED x)
      where x.nonNull {
   x.mediaType.nonNull;
};

The IANA defined domain of media types is established by the Internet standard RFC 2045 [http://www.ietf.org/rfc/rfc2045.txt] and 2046 [http://www.ietf.org/rfc/rfc2046.txt]. RFC 2046 defines the media type to consist of two parts:

1. top level media type, and
2. media subtype

However, this specification treats the entire media type as one atomic code symbol in the form defined by IANA, i.e., top level type followed by a slash "/" followed by media subtype. Currently defined media types are registered in a database [http://www.iana.org/assignments/media-types/index.html] maintained by IANA. Currently several hundred different MIME media types are defined, with the list growing rapidly. In general, all those types defined by the IANA MAY be used.

To promote interoperability, this specification prefers certain media types to others. This is to define a greatest common denominator on which interoperability is not only possible, but that is powerful enough to support even advanced multimedia communication needs.

Table below assigns a status to certain MIME media types, where the status means one of the following:

• required: Every HL7 application SHALL support at least the required media types if it supports a given kind of media. One required media-type for each kind of media exists. Some media types are required for a specific purpose, which is then indicated as "required for ..."
• recommended: Other media types are recommended for a particular purpose. For any given purpose there should be only very few additionally recommended media types and the rationale, conditions and assumptions of such recommendations must be made very clear.
• indifferent: This status means, HL7 neither forbids nor endorses the use of this media type. All media types not mentioned in Table have status indifferent by default. Since there are one required and several recommended media types for most practically relevant use cases, media types of this status should be used very conservatively.
• deprecated: Deprecated media types SHOULD NOT be used, because these media types are flawed, because there are better alternatives, or because of certain risks. Such risks could be security risks, for example, the risk that such a media type could spread computer viruses. Not every flawed media type is marked as deprecated, though. A media type that is not mentioned in Table 6, and thus has status indifferent, may well be flawed.

The set of required media types is very small so that no undue requirements are forced on HL7 applications, especially legacy systems. In general, no HL7 application is forced to support any given kind of media other than written text. For example, many systems just do not want to receive audio data, because those systems can only show written text to their users. It is a matter of application conformance statements to say: "I will not handle audio". Only if a system claims to handle audio media, then it must support the required media type for audio.

Definition:      An Internet Assigned Numbers Authority (IANA) Charset Registered character set and character encoding for character-based media types.

The charset SHALL be identified by an Internet Assigned Numbers Authority (IANA) Charset Registration [http://www.iana.org/assignments/character-sets] in accordance with RFC 2978 [http://www.ietf.org/rfc/rfc2978.txt]. The IANA source specifies names and multiple aliases for most character sets. For HL7's purposes, use of multiple alias names is not allowed. The standard name for HL7 is the one marked by IANA as "preferred for MIME." If IANA has not marked one of the aliases as "preferred for MIME" the main name SHALL be the one used for HL7.

Table 15 lists a few of the IANA defined character sets that are of interest to current HL7 members.

NOTE: The above list is not complete let alone exclusive. In particular, international HL7 affiliates may make special recommendations about charsets to be used in their realm. These recommendations MAY add additional charsets and MAY reassign the recommendations status of a listed charset.

The charset property needs to be known where the data of ED is character type data in any form. If the data is provided in-line, then the charset SHALL be clearly conveyed. If the data is provided as a reference, and the access method does not provide the charset for the data, typically as a mime header, then the charset SHALL be conveyed as part of the ED.

Interested readers may also want to consult the "Character Model for the World Wide Web" [http://www.w3.org/TR/charmod] for a more complete discussion of character set and related issues.

Definition:      The human language of the content.

The need for a language code for text data values is documented in RFC 2277, IETF Policy on Character Sets and Languages [http://www.ietf.org/rfc/rfc2277.txt]. Further background information can be found in Using International Characters in Internet Mail [http://www.imc.org/mail-i18n.html], a memo by the Internet Mail Consortium.

The principles of the code domain of this attribute are specified by the Internet standard RFC 3066 [http://www.ietf.org/rfc/rfc3066.txt]. The RFC 3066 coding scheme is principally constructed from a primary subtag component encoded using the language codes of ISO 639, with an optional second subtag component encoded using the two letter country codes of ISO 3166. Where this scheme does not provide a suitable code, RFC 3066 allows for other codes, mostly as defined by ISO or the Internet Assigned Names Authority [http://www.iana.org/assignments/language-tags].¹³ This code domain is assigned the OID 2.16.840.1.113883.6.121.

While Language tags usually alter the meaning of the text, the language does not alter the meaning of the characters in the text.¹⁴

NOTE: Representation of language tags to text is highly dependent on the ITS. An ITS MAY use the native way of language tagging provided by its target implementation technology. Some may have language information in a separate component, e.g., XML has the xml:lang tag for strings. Others may rely on language tags as part of the binary character string representation, e.g., ISO 10646 (Unicode) and its "plane-14" language tags.

The language tag SHOULD NOT be mandatory if it is not mandatory in the implementation technology. Semantically, language tagging of strings follows a default-logic. In circumstances where a realm may support multiple langauges, it is up to the realm to define rules to handle language where none is specified when no language is specified. If no other rule is specified, the local language of the reader is assumed. If a language is set for an entire message or document, that language is the default. If any information element or value that is superior in the syntax hierarchy specifies a language, that language is the default for all subordinate text values.

If language tags are present in the beginning of the encoded binary text (e.g., through Unicode's plane-14 tags) this is the source of the language property of the encapsulated data value.

Definition:      The compression algorithm, if any, used on the raw byte data.

• required: Every HL7 application SHALL support at least the required compression types.
• indifferent: This status means, HL7 neither forbids nor endorses the use of this compression algorithm.
• deprecated: Deprecated compression algorithms SHOULD NOT be used, because they are flawed, because there are better alternatives, or because of certain risks.

The compression applies to the data applied in line, not to data provided by reference, even if there is no data provided in line. Note that some compression formats allow multiple archive files to be embedded within a single compressed volume. Applications SHALL ensure that the decompressed form of the data conforms to the stated media type. The stated media type applies to the uncompressed data.

Definition:      A URL the target of which is taken as the binary content of the ED.

A telecommunication address (TEL) is a URL (i.e. for HTTP or FTP) which will resolve to precisely the same binary data that could as well have been provided as inline data. The semantic value of an encapsulated data value is the same, regardless whether the data is present inline data or just by-reference. However, an encapsulated data value without inline data behaves differently, since any attempt to examine the data requires the data to be downloaded from the reference. An encapsulated data value MAY have both inline data and a reference.

If both reference and inline data are provided, the reference SHALL point to data identical to that provided inline. It is an error if the data resolved through the reference does not match either the integrity check or the in-line data.

The reference may contain a usablePeriod to indicate that the data may only be available for a limited period of time. Whether the reference is limited by a usablePeriod or not, the content of the reference SHALL be fixed for all time. Any application using the reference SHALL always receive the same data, or an error. The reference cannot be reused to send a different version of the same data, or different data.

By-reference encapsulated data may not be allowed depending on the attribute or component that is declared encapsulated data. Values of type ST SHALL always be inline.

Definition:      A checksum calculated over the binary data.

The integrity check is a short binary value representing a cryptographically strong checksum that is calculated over the binary data. The purpose of this property, when communicated with a reference is for anyone to validate later whether the reference still resolved to the same data that the reference resolved to when the encapsulated data value with reference was created. It is an error if the data resolved through the reference does not match the integrity check.

The integrity check is calculated according to the integrityCheckAlgorithm. By default, the Secure Hash Algorithm-1 (SHA-1) shall be used. The integrity check is binary encoded according to the rules of the integrity check algorithm.

The integrity check is calculated over the raw binary data that is contained in the data component, or that is accessible through the reference. No transformations are made before the integrity check is calculated. If the data is compressed, the Integrity Check is calculated over the compressed data.

Definition:      The algorithm used to compute the integrityCheck value.

The default value is SHA-1.¹⁵

Definition:      An alternative description of the media where the context is not suitable for rendering the media.

E.g. Short text description of an image or sound clip, etc. This attribute is not intended to be a complete substitute for the original. For complete substitutes, use the "translation" property. The intent of this property is allow compliance with disability requirements such as those expressed in American's with Disability Act (also known as "Section 508"), where there is a requirement to provide a short text description of included media in some form that can be read by a screen reader. This is similar to a very short thumbnail with mediaType = text/plain.

Definition:      An abbreviated rendition of the full data.

A thumbnail requires significantly fewer resources than the full data, while still maintaining some distinctive similarity with the full data. A thumbnail is typically used with by-reference encapsulated data. It allows a user to select data more efficiently before actually downloading through the reference. Originally, the term thumbnail refers to an image in a lower resolution (or smaller size) than another image. However, the thumbnail concept can be metaphorically used for media types other than images. For example, a movie may be represented by a shorter clip; an audio-clip may be represented by another audio-clip that is shorter, has a lower sampling rate, or a lossy compression; or an abstract provided for a long document.

Thumbnails may not be allowed depending on the attribute or component that is declared encapsulated data. Values of type ST SHALL NOT have thumbnails, and a thumbnail itself SHALL NOT contain a thumbnail.

invariant(ED x)
      where x.thumbnail.nonNull {
   x.thumbnail.thumbnail.isNull;
};

NOTE: ITS's SHOULD consider the case where the thumbnail and the original both have the same properties of type, charset and compression. In this case, these properties need not be represented explicitly for the thumbnail but might be "inherited" from the main encapsulated data value to its thumbnail.

Definition:      Alternate renditions of the same content translated into a different language or a different mediaType. The translation property is a set of ED that each translate the first rendition into a different language or use a different mediaType. Each element of the translation set SHALL be a translation of the ED value. Translations SHALL NOT contain translations.

The translations SHALL convey the same information, but in a different language or mediaType. The translations do not take part in the test for equality, so SHALL NOT introduce any new semantics to the value.

invariant(ED x)
      where x.nonNull {
   forall(ED t) where x.translation.contains(t) {
     t.description.isNull;
	 t.language.equals(x.language).not.or(t.mediaType.equals(x.mediaType).not);
	 t.translation.isEmpty;
   }
};

Definition:      The length of the content in the ED.

The length of the ED may not be the same as the length of the binary content of the ED in the data property. The length is the number of items in the content where the kind of item is determined by the mediaType. For instance, if the mediatype is a type of text, then the length of the ED is the number of characters found in the binary content, as specified by the charset. For application, video, audio and image mediatypes, the length is the same as the length of the binary content.

invariant(ED x, INT y)
      where x.nonNull.and(y.isZero) {
   x.length.greaterThan(y);
};

nonNull ED SHALL always have some content, and length is greater than 0.

Definition:      A contiguous sublist of the ED containing the content found from index start to end, inclusively.

As with length, the subPart of an ED may be different to a subList of the data. The offsets are determined based on the logical contents as determined by the mediaType. For application, video, audio and image mediatypes, the offsets are the same as the offsets in the binary content. The content must then the re-rendered into some binary representation.

The mediaType and the charset of the return value are usually of the same type as the ED, but this may not always be the case.