]> 0.1 (30.05.2010 21:51:45) ANY (DataValue) Defines the basic properties of every data value. This is an abstract type, meaning that no value can be just a data value without belonging to any concrete type. Every concrete type is a specialization of this general abstract DataValue type. abstract type DataValue alias ANY { TYPE dataType; BN nonNull; BN isNull; CS nullFlavor; BL notApplicable; BL unknown; BL other; BL equal(ANY x); }; Defines the basic properties of every data value. This is an abstract type, meaning that no value can be just a data value without belonging to any concrete type. Every concrete type is a specialization of this general abstract DataValue type. abstract type DataValue alias ANY { TYPE dataType; BN nonNull; BN isNull; CS nullFlavor; BL notApplicable; BL unknown; BL other; BL equal(ANY x); }; Defines the basic properties of every data value. This is an abstract type, meaning that no value can be just a data value without belonging to any concrete type. Every concrete type is a specialization of this general abstract DataValue type. abstract type DataValue alias ANY { TYPE dataType; BN nonNull; BN isNull; CS nullFlavor; BL notApplicable; BL unknown; BL other; BL equal(ANY x); }; Defines the basic properties of every data value. This is an abstract type, meaning that no value can be just a data value without belonging to any concrete type. Every concrete type is a specialization of this general abstract DataValue type. abstract type DataValue alias ANY { TYPE dataType; BN nonNull; BN isNull; CS nullFlavor; BL notApplicable; BL unknown; BL other; BL equal(ANY x); }; Defines the basic properties of every data value. This is an abstract type, meaning that no value can be just a data value without belonging to any concrete type. Every concrete type is a specialization of this general abstract DataValue type. abstract type DataValue alias ANY { TYPE dataType; BN nonNull; BN isNull; CS nullFlavor; BL notApplicable; BL unknown; BL other; BL equal(ANY x); }; Defines the basic properties of every data value. This is an abstract type, meaning that no value can be just a data value without belonging to any concrete type. Every concrete type is a specialization of this general abstract DataValue type. abstract type DataValue alias ANY { TYPE dataType; BN nonNull; BN isNull; CS nullFlavor; BL notApplicable; BL unknown; BL other; BL equal(ANY x); }; Defines the basic properties of every data value. This is an abstract type, meaning that no value can be just a data value without belonging to any concrete type. Every concrete type is a specialization of this general abstract DataValue type. abstract type DataValue alias ANY { TYPE dataType; BN nonNull; BN isNull; CS nullFlavor; BL notApplicable; BL unknown; BL other; BL equal(ANY x); }; Defines the basic properties of every data value. This is an abstract type, meaning that no value can be just a data value without belonging to any concrete type. Every concrete type is a specialization of this general abstract DataValue type. abstract type DataValue alias ANY { TYPE dataType; BN nonNull; BN isNull; CS nullFlavor; BL notApplicable; BL unknown; BL other; BL equal(ANY x); }; Defines the basic properties of every data value. This is an abstract type, meaning that no value can be just a data value without belonging to any concrete type. Every concrete type is a specialization of this general abstract DataValue type. abstract type DataValue alias ANY { TYPE dataType; BN nonNull; BN isNull; CS nullFlavor; BL notApplicable; BL unknown; BL other; BL equal(ANY x); }; TYPE (DataType) A meta-type declared in order to allow the formal definitions to speak about the data type of a value. Any data type defined in this specification is a value of the type DataType. private type DataType alias TYPE specializes ANY { CS shortName; CS longName; BN implies(TYPE that); }; A meta-type declared in order to allow the formal definitions to speak about the data type of a value. Any data type defined in this specification is a value of the type DataType. private type DataType alias TYPE specializes ANY { CS shortName; CS longName; BN implies(TYPE that); }; A meta-type declared in order to allow the formal definitions to speak about the data type of a value. Any data type defined in this specification is a value of the type DataType. private type DataType alias TYPE specializes ANY { CS shortName; CS longName; BN implies(TYPE that); }; A meta-type declared in order to allow the formal definitions to speak about the data type of a value. Any data type defined in this specification is a value of the type DataType. private type DataType alias TYPE specializes ANY { CS shortName; CS longName; BN implies(TYPE that); }; BL (Boolean) The Boolean type stands for the values of two-valued logic. A Boolean value can be either true or false, or, as any other value may be NULL. With any data value potentially being NULL, the two-valued logic is effectively extended to a three-valued logic as shown in the following truth tables: Truth Table: NOT NOT ? true false false true NULL NULL Truth Table: AND AND true false NULL true true false NULL false false false false NULL NULL false NULL Truth Table: OR OR true false NULL true true true true false true false NULL NULL true NULL NULL Where a boolean operation is performed upon 2 data types with different nullFlavors, the nullFlavor of the result is the first common ancestor of the 2 different nullFlavors, though conformant applications may also create a result that is any common ancestor 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); literal ST; }; The Boolean type stands for the values of two-valued logic. A Boolean value can be either true or false, or, as any other value may be NULL. With any data value potentially being NULL, the two-valued logic is effectively extended to a three-valued logic as shown in the following truth tables: Truth Table: NOT NOT ? true false false true NULL NULL Truth Table: AND AND true false NULL true true false NULL false false false false NULL NULL false NULL Truth Table: OR OR true false NULL true true true true false true false NULL NULL true NULL NULL Where a boolean operation is performed upon 2 data types with different nullFlavors, the nullFlavor of the result is the first common ancestor of the 2 different nullFlavors, though conformant applications may also create a result that is any common ancestor 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); literal ST; }; The Boolean type stands for the values of two-valued logic. A Boolean value can be either true or false, or, as any other value may be NULL. With any data value potentially being NULL, the two-valued logic is effectively extended to a three-valued logic as shown in the following truth tables: Truth Table: NOT NOT ? true false false true NULL NULL Truth Table: AND AND true false NULL true true false NULL false false false false NULL NULL false NULL Truth Table: OR OR true false NULL true true true true false true false NULL NULL true NULL NULL Where a boolean operation is performed upon 2 data types with different nullFlavors, the nullFlavor of the result is the first common ancestor of the 2 different nullFlavors, though conformant applications may also create a result that is any common ancestor 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); literal ST; }; The Boolean type stands for the values of two-valued logic. A Boolean value can be either true or false, or, as any other value may be NULL. With any data value potentially being NULL, the two-valued logic is effectively extended to a three-valued logic as shown in the following truth tables: Truth Table: NOT NOT ? true false false true NULL NULL Truth Table: AND AND true false NULL true true false NULL false false false false NULL NULL false NULL Truth Table: OR OR true false NULL true true true true false true false NULL NULL true NULL NULL Where a boolean operation is performed upon 2 data types with different nullFlavors, the nullFlavor of the result is the first common ancestor of the 2 different nullFlavors, though conformant applications may also create a result that is any common ancestor 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); literal ST; }; The Boolean type stands for the values of two-valued logic. A Boolean value can be either true or false, or, as any other value may be NULL. With any data value potentially being NULL, the two-valued logic is effectively extended to a three-valued logic as shown in the following truth tables: Truth Table: NOT NOT ? true false false true NULL NULL Truth Table: AND AND true false NULL true true false NULL false false false false NULL NULL false NULL Truth Table: OR OR true false NULL true true true true false true false NULL NULL true NULL NULL Where a boolean operation is performed upon 2 data types with different nullFlavors, the nullFlavor of the result is the first common ancestor of the 2 different nullFlavors, though conformant applications may also create a result that is any common ancestor 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); literal ST; }; The Boolean type stands for the values of two-valued logic. A Boolean value can be either true or false, or, as any other value may be NULL. With any data value potentially being NULL, the two-valued logic is effectively extended to a three-valued logic as shown in the following truth tables: Truth Table: NOT NOT ? true false false true NULL NULL Truth Table: AND AND true false NULL true true false NULL false false false false NULL NULL false NULL Truth Table: OR OR true false NULL true true true true false true false NULL NULL true NULL NULL Where a boolean operation is performed upon 2 data types with different nullFlavors, the nullFlavor of the result is the first common ancestor of the 2 different nullFlavors, though conformant applications may also create a result that is any common ancestor 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); literal ST; }; The Boolean type stands for the values of two-valued logic. A Boolean value can be either true or false, or, as any other value may be NULL. With any data value potentially being NULL, the two-valued logic is effectively extended to a three-valued logic as shown in the following truth tables: Truth Table: NOT NOT ? true false false true NULL NULL Truth Table: AND AND true false NULL true true false NULL false false false false NULL NULL false NULL Truth Table: OR OR true false NULL true true true true false true false NULL NULL true NULL NULL Where a boolean operation is performed upon 2 data types with different nullFlavors, the nullFlavor of the result is the first common ancestor of the 2 different nullFlavors, though conformant applications may also create a result that is any common ancestor 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); literal ST; }; BN (BooleanNonNull) The BooleanNonNull constrains the boolean type so that the value may not be NULL. This type is created for use within the data types specification where it is not appropriate for a null value to be used private type BooleanNonNull alias BN specializes BL; The BooleanNonNull constrains the boolean type so that the value may not be NULL. This type is created for use within the data types specification where it is not appropriate for a null value to be used private type BooleanNonNull alias BN specializes BL; BIN (BinaryData) Binary data is a raw block of bits. Binary data is a protected type that should not be declared outside the data type specification. A bit is semantically identical with a non-null Boolean value. Thus, all binary data is - semantically - a sequence of non-null Boolean values. protected type BinaryData alias BIN specializes LIST<BN>; the representation of arbitrary binary data is the responsibility of an ITS. How the ITS accomplishes this depends on the underlying Implementation Technology (whether it is character-based or binary) and on the represented data. Semantically character data is represented as binary data, however, a character-based ITS should not convert character data into arbitrary binary data and then represent binary data in a character encoding. Ultimately even character-based implementation technology will communicate binary data. ED (EncapsulatedData) Data that is primarily intended for human interpretation or for further machine processing outside the scope of HL7. This includes unformatted or formatted written language, multimedia data, or structured information in as defined by a different standard (e.g., XML-signatures.) Instead of the data itself, an may contain only a reference (see .) Note that the data type is a specialization of the data type when the media type is text/plain. Encapsulated data can be present in two forms, inline or by reference. Inline data is communicated or moved as part of the encapsulated data value, whereas by-reference data may reside at a different (remote) location. The data is the same whether it is located inline or remote. type EncapsulatedData alias ED specializes BIN { CS mediaType; CS charset; CS language; CS compression; TEL reference; BIN integrityCheck; CS integrityCheckAlgorithm; ED thumbnail; }; Data that is primarily intended for human interpretation or for further machine processing outside the scope of HL7. This includes unformatted or formatted written language, multimedia data, or structured information in as defined by a different standard (e.g., XML-signatures.) Instead of the data itself, an may contain only a reference (see .) Note that the data type is a specialization of the data type when the media type is text/plain. Encapsulated data can be present in two forms, inline or by reference. Inline data is communicated or moved as part of the encapsulated data value, whereas by-reference data may reside at a different (remote) location. The data is the same whether it is located inline or remote. type EncapsulatedData alias ED specializes BIN { CS mediaType; CS charset; CS language; CS compression; TEL reference; BIN integrityCheck; CS integrityCheckAlgorithm; ED thumbnail; }; Data that is primarily intended for human interpretation or for further machine processing outside the scope of HL7. This includes unformatted or formatted written language, multimedia data, or structured information in as defined by a different standard (e.g., XML-signatures.) Instead of the data itself, an may contain only a reference (see .) Note that the data type is a specialization of the data type when the media type is text/plain. Encapsulated data can be present in two forms, inline or by reference. Inline data is communicated or moved as part of the encapsulated data value, whereas by-reference data may reside at a different (remote) location. The data is the same whether it is located inline or remote. type EncapsulatedData alias ED specializes BIN { CS mediaType; CS charset; CS language; CS compression; TEL reference; BIN integrityCheck; CS integrityCheckAlgorithm; ED thumbnail; }; Data that is primarily intended for human interpretation or for further machine processing outside the scope of HL7. This includes unformatted or formatted written language, multimedia data, or structured information in as defined by a different standard (e.g., XML-signatures.) Instead of the data itself, an may contain only a reference (see .) Note that the data type is a specialization of the data type when the media type is text/plain. Encapsulated data can be present in two forms, inline or by reference. Inline data is communicated or moved as part of the encapsulated data value, whereas by-reference data may reside at a different (remote) location. The data is the same whether it is located inline or remote. type EncapsulatedData alias ED specializes BIN { CS mediaType; CS charset; CS language; CS compression; TEL reference; BIN integrityCheck; CS integrityCheckAlgorithm; ED thumbnail; }; Data that is primarily intended for human interpretation or for further machine processing outside the scope of HL7. This includes unformatted or formatted written language, multimedia data, or structured information in as defined by a different standard (e.g., XML-signatures.) Instead of the data itself, an may contain only a reference (see .) Note that the data type is a specialization of the data type when the media type is text/plain. Encapsulated data can be present in two forms, inline or by reference. Inline data is communicated or moved as part of the encapsulated data value, whereas by-reference data may reside at a different (remote) location. The data is the same whether it is located inline or remote. type EncapsulatedData alias ED specializes BIN { CS mediaType; CS charset; CS language; CS compression; TEL reference; BIN integrityCheck; CS integrityCheckAlgorithm; ED thumbnail; }; Data that is primarily intended for human interpretation or for further machine processing outside the scope of HL7. This includes unformatted or formatted written language, multimedia data, or structured information in as defined by a different standard (e.g., XML-signatures.) Instead of the data itself, an may contain only a reference (see .) Note that the data type is a specialization of the data type when the media type is text/plain. Encapsulated data can be present in two forms, inline or by reference. Inline data is communicated or moved as part of the encapsulated data value, whereas by-reference data may reside at a different (remote) location. The data is the same whether it is located inline or remote. type EncapsulatedData alias ED specializes BIN { CS mediaType; CS charset; CS language; CS compression; TEL reference; BIN integrityCheck; CS integrityCheckAlgorithm; ED thumbnail; }; Data that is primarily intended for human interpretation or for further machine processing outside the scope of HL7. This includes unformatted or formatted written language, multimedia data, or structured information in as defined by a different standard (e.g., XML-signatures.) Instead of the data itself, an may contain only a reference (see .) Note that the data type is a specialization of the data type when the media type is text/plain. Encapsulated data can be present in two forms, inline or by reference. Inline data is communicated or moved as part of the encapsulated data value, whereas by-reference data may reside at a different (remote) location. The data is the same whether it is located inline or remote. type EncapsulatedData alias ED specializes BIN { CS mediaType; CS charset; CS language; CS compression; TEL reference; BIN integrityCheck; CS integrityCheckAlgorithm; ED thumbnail; }; Data that is primarily intended for human interpretation or for further machine processing outside the scope of HL7. This includes unformatted or formatted written language, multimedia data, or structured information in as defined by a different standard (e.g., XML-signatures.) Instead of the data itself, an may contain only a reference (see .) Note that the data type is a specialization of the data type when the media type is text/plain. Encapsulated data can be present in two forms, inline or by reference. Inline data is communicated or moved as part of the encapsulated data value, whereas by-reference data may reside at a different (remote) location. The data is the same whether it is located inline or remote. type EncapsulatedData alias ED specializes BIN { CS mediaType; CS charset; CS language; CS compression; TEL reference; BIN integrityCheck; CS integrityCheckAlgorithm; ED thumbnail; }; Data that is primarily intended for human interpretation or for further machine processing outside the scope of HL7. This includes unformatted or formatted written language, multimedia data, or structured information in as defined by a different standard (e.g., XML-signatures.) Instead of the data itself, an may contain only a reference (see .) Note that the data type is a specialization of the data type when the media type is text/plain. Encapsulated data can be present in two forms, inline or by reference. Inline data is communicated or moved as part of the encapsulated data value, whereas by-reference data may reside at a different (remote) location. The data is the same whether it is located inline or remote. type EncapsulatedData alias ED specializes BIN { CS mediaType; CS charset; CS language; CS compression; TEL reference; BIN integrityCheck; CS integrityCheckAlgorithm; ED thumbnail; }; Data that is primarily intended for human interpretation or for further machine processing outside the scope of HL7. This includes unformatted or formatted written language, multimedia data, or structured information in as defined by a different standard (e.g., XML-signatures.) Instead of the data itself, an may contain only a reference (see .) Note that the data type is a specialization of the data type when the media type is text/plain. Encapsulated data can be present in two forms, inline or by reference. Inline data is communicated or moved as part of the encapsulated data value, whereas by-reference data may reside at a different (remote) location. The data is the same whether it is located inline or remote. type EncapsulatedData alias ED specializes BIN { CS mediaType; CS charset; CS language; CS compression; TEL reference; BIN integrityCheck; CS integrityCheckAlgorithm; ED thumbnail; }; ST (CharacterString) The character string data type stands for text data, primarily intended for machine processing (e.g., sorting, querying, indexing, etc.) Used for names, symbols, and formal expressions. Requirement: ST is a specialization of ED so that any RIM attribute which has the type ED can be constrained to a ST. The most important case is Act.text, which is an ED to cater for the use of references and multimedia data, but is often constrained to plain text. The character string is a restricted encapsulated data type ( ), whose type property is fixed to text/plain, and whose data must be inlined and not compressed. Thus, the properties compression, reference, integrity check, algorithm, and thumbnail are not applicable. The character string data type is used when the appearance of text does not bear meaning, which is true for formalized text and all kinds of names. The character string (ST) data type interprets the encapsulated data as character data (as opposed to bits), depending on the charset property of the encapsulated data type. The headCharacter and tailString properties define ST as a sequence of entities each of which uniquely identifies one character from the joint set of all characters known by any language of the world. ISO/IEC 10646-1: 1993 defines a character as "A member of a set of elements used for the organization, control, or representation of data." ISO/IEC TR 15285 - An operational model for characters and glyphs. Discusses the problems involved in defining characters. Notably, characters are abstract entities of information, independent of type font or language. The ISO 10646 (UNICODE [http://www.unicode.org]) - or in Japan, JIS X0221 - is a globally applicable character set that uniquely identifies all characters of any language in the world. In this specification, ISO 10646 serves as a semantic model for character strings. The important point is that for semantic purposes, there is no notion of separate character sets and switching between character sets. Character set and character encoding are ITS layer considerations. The formal definition gives indication to this effect because each character is by itself an value that has a charset property. Thus, the binary encoding of each character is always understood in the context of a certain character set. This does not mean that the ITS should represent a character string as a sequence of full blown values. What it means is that on the application layer the notion of character encoding is irrelevant when we deal with character strings. The length of a character string is the number of characters in the string. The head of a string is a string of only one character. A character string must at least have one character or else it is NULL. A zero-length string is an exceptional value (NULL), not a proper character string value. The length of a string is the number of characters, not the number of encoded bytes. Byte encoding is an ITS issue and is not relevant on the application layer. The following rules apply to whitespace contained within character strings: TAB, space and end-of-line are all considered whitespace characters. Both preceding and trailing whitespace is significant. Different whitespace characters are not interchangable. Different representations of end-of-line are normalised according to the method described in the XML specification [] Sequences of whitespace cannot be compressed to shorter sequences. type CharacterString alias ST specializes ED { ST headCharacter; ST tailString; literal ST; }; The character string data type stands for text data, primarily intended for machine processing (e.g., sorting, querying, indexing, etc.) Used for names, symbols, and formal expressions. Requirement: ST is a specialization of ED so that any RIM attribute which has the type ED can be constrained to a ST. The most important case is Act.text, which is an ED to cater for the use of references and multimedia data, but is often constrained to plain text. The character string is a restricted encapsulated data type ( ), whose type property is fixed to text/plain, and whose data must be inlined and not compressed. Thus, the properties compression, reference, integrity check, algorithm, and thumbnail are not applicable. The character string data type is used when the appearance of text does not bear meaning, which is true for formalized text and all kinds of names. The character string (ST) data type interprets the encapsulated data as character data (as opposed to bits), depending on the charset property of the encapsulated data type. The headCharacter and tailString properties define ST as a sequence of entities each of which uniquely identifies one character from the joint set of all characters known by any language of the world. ISO/IEC 10646-1: 1993 defines a character as "A member of a set of elements used for the organization, control, or representation of data." ISO/IEC TR 15285 - An operational model for characters and glyphs. Discusses the problems involved in defining characters. Notably, characters are abstract entities of information, independent of type font or language. The ISO 10646 (UNICODE [http://www.unicode.org]) - or in Japan, JIS X0221 - is a globally applicable character set that uniquely identifies all characters of any language in the world. In this specification, ISO 10646 serves as a semantic model for character strings. The important point is that for semantic purposes, there is no notion of separate character sets and switching between character sets. Character set and character encoding are ITS layer considerations. The formal definition gives indication to this effect because each character is by itself an value that has a charset property. Thus, the binary encoding of each character is always understood in the context of a certain character set. This does not mean that the ITS should represent a character string as a sequence of full blown values. What it means is that on the application layer the notion of character encoding is irrelevant when we deal with character strings. The length of a character string is the number of characters in the string. The head of a string is a string of only one character. A character string must at least have one character or else it is NULL. A zero-length string is an exceptional value (NULL), not a proper character string value. The length of a string is the number of characters, not the number of encoded bytes. Byte encoding is an ITS issue and is not relevant on the application layer. The following rules apply to whitespace contained within character strings: TAB, space and end-of-line are all considered whitespace characters. Both preceding and trailing whitespace is significant. Different whitespace characters are not interchangable. Different representations of end-of-line are normalised according to the method described in the XML specification [] Sequences of whitespace cannot be compressed to shorter sequences. type CharacterString alias ST specializes ED { ST headCharacter; ST tailString; literal ST; }; The character string data type stands for text data, primarily intended for machine processing (e.g., sorting, querying, indexing, etc.) Used for names, symbols, and formal expressions. Requirement: ST is a specialization of ED so that any RIM attribute which has the type ED can be constrained to a ST. The most important case is Act.text, which is an ED to cater for the use of references and multimedia data, but is often constrained to plain text. The character string is a restricted encapsulated data type ( ), whose type property is fixed to text/plain, and whose data must be inlined and not compressed. Thus, the properties compression, reference, integrity check, algorithm, and thumbnail are not applicable. The character string data type is used when the appearance of text does not bear meaning, which is true for formalized text and all kinds of names. The character string (ST) data type interprets the encapsulated data as character data (as opposed to bits), depending on the charset property of the encapsulated data type. The headCharacter and tailString properties define ST as a sequence of entities each of which uniquely identifies one character from the joint set of all characters known by any language of the world. ISO/IEC 10646-1: 1993 defines a character as "A member of a set of elements used for the organization, control, or representation of data." ISO/IEC TR 15285 - An operational model for characters and glyphs. Discusses the problems involved in defining characters. Notably, characters are abstract entities of information, independent of type font or language. The ISO 10646 (UNICODE [http://www.unicode.org]) - or in Japan, JIS X0221 - is a globally applicable character set that uniquely identifies all characters of any language in the world. In this specification, ISO 10646 serves as a semantic model for character strings. The important point is that for semantic purposes, there is no notion of separate character sets and switching between character sets. Character set and character encoding are ITS layer considerations. The formal definition gives indication to this effect because each character is by itself an value that has a charset property. Thus, the binary encoding of each character is always understood in the context of a certain character set. This does not mean that the ITS should represent a character string as a sequence of full blown values. What it means is that on the application layer the notion of character encoding is irrelevant when we deal with character strings. The length of a character string is the number of characters in the string. The head of a string is a string of only one character. A character string must at least have one character or else it is NULL. A zero-length string is an exceptional value (NULL), not a proper character string value. The length of a string is the number of characters, not the number of encoded bytes. Byte encoding is an ITS issue and is not relevant on the application layer. The following rules apply to whitespace contained within character strings: TAB, space and end-of-line are all considered whitespace characters. Both preceding and trailing whitespace is significant. Different whitespace characters are not interchangable. Different representations of end-of-line are normalised according to the method described in the XML specification [] Sequences of whitespace cannot be compressed to shorter sequences. type CharacterString alias ST specializes ED { ST headCharacter; ST tailString; literal ST; }; The character string data type stands for text data, primarily intended for machine processing (e.g., sorting, querying, indexing, etc.) Used for names, symbols, and formal expressions. Requirement: ST is a specialization of ED so that any RIM attribute which has the type ED can be constrained to a ST. The most important case is Act.text, which is an ED to cater for the use of references and multimedia data, but is often constrained to plain text. The character string is a restricted encapsulated data type ( ), whose type property is fixed to text/plain, and whose data must be inlined and not compressed. Thus, the properties compression, reference, integrity check, algorithm, and thumbnail are not applicable. The character string data type is used when the appearance of text does not bear meaning, which is true for formalized text and all kinds of names. The character string (ST) data type interprets the encapsulated data as character data (as opposed to bits), depending on the charset property of the encapsulated data type. The headCharacter and tailString properties define ST as a sequence of entities each of which uniquely identifies one character from the joint set of all characters known by any language of the world. ISO/IEC 10646-1: 1993 defines a character as "A member of a set of elements used for the organization, control, or representation of data." ISO/IEC TR 15285 - An operational model for characters and glyphs. Discusses the problems involved in defining characters. Notably, characters are abstract entities of information, independent of type font or language. The ISO 10646 (UNICODE [http://www.unicode.org]) - or in Japan, JIS X0221 - is a globally applicable character set that uniquely identifies all characters of any language in the world. In this specification, ISO 10646 serves as a semantic model for character strings. The important point is that for semantic purposes, there is no notion of separate character sets and switching between character sets. Character set and character encoding are ITS layer considerations. The formal definition gives indication to this effect because each character is by itself an value that has a charset property. Thus, the binary encoding of each character is always understood in the context of a certain character set. This does not mean that the ITS should represent a character string as a sequence of full blown values. What it means is that on the application layer the notion of character encoding is irrelevant when we deal with character strings. The length of a character string is the number of characters in the string. The head of a string is a string of only one character. A character string must at least have one character or else it is NULL. A zero-length string is an exceptional value (NULL), not a proper character string value. The length of a string is the number of characters, not the number of encoded bytes. Byte encoding is an ITS issue and is not relevant on the application layer. The following rules apply to whitespace contained within character strings: TAB, space and end-of-line are all considered whitespace characters. Both preceding and trailing whitespace is significant. Different whitespace characters are not interchangable. Different representations of end-of-line are normalised according to the method described in the XML specification [] Sequences of whitespace cannot be compressed to shorter sequences. type CharacterString alias ST specializes ED { ST headCharacter; ST tailString; literal ST; }; The character string data type stands for text data, primarily intended for machine processing (e.g., sorting, querying, indexing, etc.) Used for names, symbols, and formal expressions. Requirement: ST is a specialization of ED so that any RIM attribute which has the type ED can be constrained to a ST. The most important case is Act.text, which is an ED to cater for the use of references and multimedia data, but is often constrained to plain text. The character string is a restricted encapsulated data type ( ), whose type property is fixed to text/plain, and whose data must be inlined and not compressed. Thus, the properties compression, reference, integrity check, algorithm, and thumbnail are not applicable. The character string data type is used when the appearance of text does not bear meaning, which is true for formalized text and all kinds of names. The character string (ST) data type interprets the encapsulated data as character data (as opposed to bits), depending on the charset property of the encapsulated data type. The headCharacter and tailString properties define ST as a sequence of entities each of which uniquely identifies one character from the joint set of all characters known by any language of the world. ISO/IEC 10646-1: 1993 defines a character as "A member of a set of elements used for the organization, control, or representation of data." ISO/IEC TR 15285 - An operational model for characters and glyphs. Discusses the problems involved in defining characters. Notably, characters are abstract entities of information, independent of type font or language. The ISO 10646 (UNICODE [http://www.unicode.org]) - or in Japan, JIS X0221 - is a globally applicable character set that uniquely identifies all characters of any language in the world. In this specification, ISO 10646 serves as a semantic model for character strings. The important point is that for semantic purposes, there is no notion of separate character sets and switching between character sets. Character set and character encoding are ITS layer considerations. The formal definition gives indication to this effect because each character is by itself an value that has a charset property. Thus, the binary encoding of each character is always understood in the context of a certain character set. This does not mean that the ITS should represent a character string as a sequence of full blown values. What it means is that on the application layer the notion of character encoding is irrelevant when we deal with character strings. The length of a character string is the number of characters in the string. The head of a string is a string of only one character. A character string must at least have one character or else it is NULL. A zero-length string is an exceptional value (NULL), not a proper character string value. The length of a string is the number of characters, not the number of encoded bytes. Byte encoding is an ITS issue and is not relevant on the application layer. The following rules apply to whitespace contained within character strings: TAB, space and end-of-line are all considered whitespace characters. Both preceding and trailing whitespace is significant. Different whitespace characters are not interchangable. Different representations of end-of-line are normalised according to the method described in the XML specification [] Sequences of whitespace cannot be compressed to shorter sequences. type CharacterString alias ST specializes ED { ST headCharacter; ST tailString; literal ST; }; The character string data type stands for text data, primarily intended for machine processing (e.g., sorting, querying, indexing, etc.) Used for names, symbols, and formal expressions. Requirement: ST is a specialization of ED so that any RIM attribute which has the type ED can be constrained to a ST. The most important case is Act.text, which is an ED to cater for the use of references and multimedia data, but is often constrained to plain text. The character string is a restricted encapsulated data type ( ), whose type property is fixed to text/plain, and whose data must be inlined and not compressed. Thus, the properties compression, reference, integrity check, algorithm, and thumbnail are not applicable. The character string data type is used when the appearance of text does not bear meaning, which is true for formalized text and all kinds of names. The character string (ST) data type interprets the encapsulated data as character data (as opposed to bits), depending on the charset property of the encapsulated data type. The headCharacter and tailString properties define ST as a sequence of entities each of which uniquely identifies one character from the joint set of all characters known by any language of the world. ISO/IEC 10646-1: 1993 defines a character as "A member of a set of elements used for the organization, control, or representation of data." ISO/IEC TR 15285 - An operational model for characters and glyphs. Discusses the problems involved in defining characters. Notably, characters are abstract entities of information, independent of type font or language. The ISO 10646 (UNICODE [http://www.unicode.org]) - or in Japan, JIS X0221 - is a globally applicable character set that uniquely identifies all characters of any language in the world. In this specification, ISO 10646 serves as a semantic model for character strings. The important point is that for semantic purposes, there is no notion of separate character sets and switching between character sets. Character set and character encoding are ITS layer considerations. The formal definition gives indication to this effect because each character is by itself an value that has a charset property. Thus, the binary encoding of each character is always understood in the context of a certain character set. This does not mean that the ITS should represent a character string as a sequence of full blown values. What it means is that on the application layer the notion of character encoding is irrelevant when we deal with character strings. The length of a character string is the number of characters in the string. The head of a string is a string of only one character. A character string must at least have one character or else it is NULL. A zero-length string is an exceptional value (NULL), not a proper character string value. The length of a string is the number of characters, not the number of encoded bytes. Byte encoding is an ITS issue and is not relevant on the application layer. The following rules apply to whitespace contained within character strings: TAB, space and end-of-line are all considered whitespace characters. Both preceding and trailing whitespace is significant. Different whitespace characters are not interchangable. Different representations of end-of-line are normalised according to the method described in the XML specification [] Sequences of whitespace cannot be compressed to shorter sequences. type CharacterString alias ST specializes ED { ST headCharacter; ST tailString; literal ST; }; The character string data type stands for text data, primarily intended for machine processing (e.g., sorting, querying, indexing, etc.) Used for names, symbols, and formal expressions. Requirement: ST is a specialization of ED so that any RIM attribute which has the type ED can be constrained to a ST. The most important case is Act.text, which is an ED to cater for the use of references and multimedia data, but is often constrained to plain text. The character string is a restricted encapsulated data type ( ), whose type property is fixed to text/plain, and whose data must be inlined and not compressed. Thus, the properties compression, reference, integrity check, algorithm, and thumbnail are not applicable. The character string data type is used when the appearance of text does not bear meaning, which is true for formalized text and all kinds of names. The character string (ST) data type interprets the encapsulated data as character data (as opposed to bits), depending on the charset property of the encapsulated data type. The headCharacter and tailString properties define ST as a sequence of entities each of which uniquely identifies one character from the joint set of all characters known by any language of the world. ISO/IEC 10646-1: 1993 defines a character as "A member of a set of elements used for the organization, control, or representation of data." ISO/IEC TR 15285 - An operational model for characters and glyphs. Discusses the problems involved in defining characters. Notably, characters are abstract entities of information, independent of type font or language. The ISO 10646 (UNICODE [http://www.unicode.org]) - or in Japan, JIS X0221 - is a globally applicable character set that uniquely identifies all characters of any language in the world. In this specification, ISO 10646 serves as a semantic model for character strings. The important point is that for semantic purposes, there is no notion of separate character sets and switching between character sets. Character set and character encoding are ITS layer considerations. The formal definition gives indication to this effect because each character is by itself an value that has a charset property. Thus, the binary encoding of each character is always understood in the context of a certain character set. This does not mean that the ITS should represent a character string as a sequence of full blown values. What it means is that on the application layer the notion of character encoding is irrelevant when we deal with character strings. The length of a character string is the number of characters in the string. The head of a string is a string of only one character. A character string must at least have one character or else it is NULL. A zero-length string is an exceptional value (NULL), not a proper character string value. The length of a string is the number of characters, not the number of encoded bytes. Byte encoding is an ITS issue and is not relevant on the application layer. The following rules apply to whitespace contained within character strings: TAB, space and end-of-line are all considered whitespace characters. Both preceding and trailing whitespace is significant. Different whitespace characters are not interchangable. Different representations of end-of-line are normalised according to the method described in the XML specification [] Sequences of whitespace cannot be compressed to shorter sequences. type CharacterString alias ST specializes ED { ST headCharacter; ST tailString; literal ST; }; The character string data type stands for text data, primarily intended for machine processing (e.g., sorting, querying, indexing, etc.) Used for names, symbols, and formal expressions. Requirement: ST is a specialization of ED so that any RIM attribute which has the type ED can be constrained to a ST. The most important case is Act.text, which is an ED to cater for the use of references and multimedia data, but is often constrained to plain text. The character string is a restricted encapsulated data type ( ), whose type property is fixed to text/plain, and whose data must be inlined and not compressed. Thus, the properties compression, reference, integrity check, algorithm, and thumbnail are not applicable. The character string data type is used when the appearance of text does not bear meaning, which is true for formalized text and all kinds of names. The character string (ST) data type interprets the encapsulated data as character data (as opposed to bits), depending on the charset property of the encapsulated data type. The headCharacter and tailString properties define ST as a sequence of entities each of which uniquely identifies one character from the joint set of all characters known by any language of the world. ISO/IEC 10646-1: 1993 defines a character as "A member of a set of elements used for the organization, control, or representation of data." ISO/IEC TR 15285 - An operational model for characters and glyphs. Discusses the problems involved in defining characters. Notably, characters are abstract entities of information, independent of type font or language. The ISO 10646 (UNICODE [http://www.unicode.org]) - or in Japan, JIS X0221 - is a globally applicable character set that uniquely identifies all characters of any language in the world. In this specification, ISO 10646 serves as a semantic model for character strings. The important point is that for semantic purposes, there is no notion of separate character sets and switching between character sets. Character set and character encoding are ITS layer considerations. The formal definition gives indication to this effect because each character is by itself an value that has a charset property. Thus, the binary encoding of each character is always understood in the context of a certain character set. This does not mean that the ITS should represent a character string as a sequence of full blown values. What it means is that on the application layer the notion of character encoding is irrelevant when we deal with character strings. The length of a character string is the number of characters in the string. The head of a string is a string of only one character. A character string must at least have one character or else it is NULL. A zero-length string is an exceptional value (NULL), not a proper character string value. The length of a string is the number of characters, not the number of encoded bytes. Byte encoding is an ITS issue and is not relevant on the application layer. The following rules apply to whitespace contained within character strings: TAB, space and end-of-line are all considered whitespace characters. Both preceding and trailing whitespace is significant. Different whitespace characters are not interchangable. Different representations of end-of-line are normalised according to the method described in the XML specification [] Sequences of whitespace cannot be compressed to shorter sequences. type CharacterString alias ST specializes ED { ST headCharacter; ST tailString; literal ST; }; The character string data type stands for text data, primarily intended for machine processing (e.g., sorting, querying, indexing, etc.) Used for names, symbols, and formal expressions. Requirement: ST is a specialization of ED so that any RIM attribute which has the type ED can be constrained to a ST. The most important case is Act.text, which is an ED to cater for the use of references and multimedia data, but is often constrained to plain text. The character string is a restricted encapsulated data type ( ), whose type property is fixed to text/plain, and whose data must be inlined and not compressed. Thus, the properties compression, reference, integrity check, algorithm, and thumbnail are not applicable. The character string data type is used when the appearance of text does not bear meaning, which is true for formalized text and all kinds of names. The character string (ST) data type interprets the encapsulated data as character data (as opposed to bits), depending on the charset property of the encapsulated data type. The headCharacter and tailString properties define ST as a sequence of entities each of which uniquely identifies one character from the joint set of all characters known by any language of the world. ISO/IEC 10646-1: 1993 defines a character as "A member of a set of elements used for the organization, control, or representation of data." ISO/IEC TR 15285 - An operational model for characters and glyphs. Discusses the problems involved in defining characters. Notably, characters are abstract entities of information, independent of type font or language. The ISO 10646 (UNICODE [http://www.unicode.org]) - or in Japan, JIS X0221 - is a globally applicable character set that uniquely identifies all characters of any language in the world. In this specification, ISO 10646 serves as a semantic model for character strings. The important point is that for semantic purposes, there is no notion of separate character sets and switching between character sets. Character set and character encoding are ITS layer considerations. The formal definition gives indication to this effect because each character is by itself an value that has a charset property. Thus, the binary encoding of each character is always understood in the context of a certain character set. This does not mean that the ITS should represent a character string as a sequence of full blown values. What it means is that on the application layer the notion of character encoding is irrelevant when we deal with character strings. The length of a character string is the number of characters in the string. The head of a string is a string of only one character. A character string must at least have one character or else it is NULL. A zero-length string is an exceptional value (NULL), not a proper character string value. The length of a string is the number of characters, not the number of encoded bytes. Byte encoding is an ITS issue and is not relevant on the application layer. The following rules apply to whitespace contained within character strings: TAB, space and end-of-line are all considered whitespace characters. Both preceding and trailing whitespace is significant. Different whitespace characters are not interchangable. Different representations of end-of-line are normalised according to the method described in the XML specification [] Sequences of whitespace cannot be compressed to shorter sequences. type CharacterString alias ST specializes ED { ST headCharacter; ST tailString; literal ST; }; The character string data type stands for text data, primarily intended for machine processing (e.g., sorting, querying, indexing, etc.) Used for names, symbols, and formal expressions. Requirement: ST is a specialization of ED so that any RIM attribute which has the type ED can be constrained to a ST. The most important case is Act.text, which is an ED to cater for the use of references and multimedia data, but is often constrained to plain text. The character string is a restricted encapsulated data type ( ), whose type property is fixed to text/plain, and whose data must be inlined and not compressed. Thus, the properties compression, reference, integrity check, algorithm, and thumbnail are not applicable. The character string data type is used when the appearance of text does not bear meaning, which is true for formalized text and all kinds of names. The character string (ST) data type interprets the encapsulated data as character data (as opposed to bits), depending on the charset property of the encapsulated data type. The headCharacter and tailString properties define ST as a sequence of entities each of which uniquely identifies one character from the joint set of all characters known by any language of the world. ISO/IEC 10646-1: 1993 defines a character as "A member of a set of elements used for the organization, control, or representation of data." ISO/IEC TR 15285 - An operational model for characters and glyphs. Discusses the problems involved in defining characters. Notably, characters are abstract entities of information, independent of type font or language. The ISO 10646 (UNICODE [http://www.unicode.org]) - or in Japan, JIS X0221 - is a globally applicable character set that uniquely identifies all characters of any language in the world. In this specification, ISO 10646 serves as a semantic model for character strings. The important point is that for semantic purposes, there is no notion of separate character sets and switching between character sets. Character set and character encoding are ITS layer considerations. The formal definition gives indication to this effect because each character is by itself an value that has a charset property. Thus, the binary encoding of each character is always understood in the context of a certain character set. This does not mean that the ITS should represent a character string as a sequence of full blown values. What it means is that on the application layer the notion of character encoding is irrelevant when we deal with character strings. The length of a character string is the number of characters in the string. The head of a string is a string of only one character. A character string must at least have one character or else it is NULL. A zero-length string is an exceptional value (NULL), not a proper character string value. The length of a string is the number of characters, not the number of encoded bytes. Byte encoding is an ITS issue and is not relevant on the application layer. The following rules apply to whitespace contained within character strings: TAB, space and end-of-line are all considered whitespace characters. Both preceding and trailing whitespace is significant. Different whitespace characters are not interchangable. Different representations of end-of-line are normalised according to the method described in the XML specification [] Sequences of whitespace cannot be compressed to shorter sequences. type CharacterString alias ST specializes ED { ST headCharacter; ST tailString; literal ST; }; The character string data type stands for text data, primarily intended for machine processing (e.g., sorting, querying, indexing, etc.) Used for names, symbols, and formal expressions. Requirement: ST is a specialization of ED so that any RIM attribute which has the type ED can be constrained to a ST. The most important case is Act.text, which is an ED to cater for the use of references and multimedia data, but is often constrained to plain text. The character string is a restricted encapsulated data type ( ), whose type property is fixed to text/plain, and whose data must be inlined and not compressed. Thus, the properties compression, reference, integrity check, algorithm, and thumbnail are not applicable. The character string data type is used when the appearance of text does not bear meaning, which is true for formalized text and all kinds of names. The character string (ST) data type interprets the encapsulated data as character data (as opposed to bits), depending on the charset property of the encapsulated data type. The headCharacter and tailString properties define ST as a sequence of entities each of which uniquely identifies one character from the joint set of all characters known by any language of the world. ISO/IEC 10646-1: 1993 defines a character as "A member of a set of elements used for the organization, control, or representation of data." ISO/IEC TR 15285 - An operational model for characters and glyphs. Discusses the problems involved in defining characters. Notably, characters are abstract entities of information, independent of type font or language. The ISO 10646 (UNICODE [http://www.unicode.org]) - or in Japan, JIS X0221 - is a globally applicable character set that uniquely identifies all characters of any language in the world. In this specification, ISO 10646 serves as a semantic model for character strings. The important point is that for semantic purposes, there is no notion of separate character sets and switching between character sets. Character set and character encoding are ITS layer considerations. The formal definition gives indication to this effect because each character is by itself an value that has a charset property. Thus, the binary encoding of each character is always understood in the context of a certain character set. This does not mean that the ITS should represent a character string as a sequence of full blown values. What it means is that on the application layer the notion of character encoding is irrelevant when we deal with character strings. The length of a character string is the number of characters in the string. The head of a string is a string of only one character. A character string must at least have one character or else it is NULL. A zero-length string is an exceptional value (NULL), not a proper character string value. The length of a string is the number of characters, not the number of encoded bytes. Byte encoding is an ITS issue and is not relevant on the application layer. The following rules apply to whitespace contained within character strings: TAB, space and end-of-line are all considered whitespace characters. Both preceding and trailing whitespace is significant. Different whitespace characters are not interchangable. Different representations of end-of-line are normalised according to the method described in the XML specification [] Sequences of whitespace cannot be compressed to shorter sequences. type CharacterString alias ST specializes ED { ST headCharacter; ST tailString; literal ST; }; CD (ConceptDescriptor) A concept descriptor represents any kind of concept usually by giving a code defined in a code system. A concept descriptor can contain the original text or phrase that served as the basis of the coding and one or more translations into different coding systems. A concept descriptor can also contain qualifiers to describe, e.g., the concept of a "left foot" as a postcoordinated term built from the primary code "FOOT" and the qualifier "LEFT". In cases of an exceptional value, the concept descriptor need not contain a code but only the original text describing that concept. The concept descriptor is mostly used in one of its restricted or 'profiled' forms, CS, CE, CV. Use of the full concept descriptor data type is not common. It requires a conscious decision and documented rationale. In all other cases, one of the restrictions shall be used. The advantage of the concept descriptor data type is its expressiveness, however, if all of its features, such as coding exceptions, text, translations and qualifiers are used at all times, implementation and use become very difficult and unsafe. Therefore, the type is most often used in a restricted form with reduced features. All restrictions constrain certain properties of the . Properties may be constrained to the extent that only one value may be allowed for that property, in which case mentioning the property becomes redundant. Constraining a property to one value is referred to as suppressing that property. Although, conceptually a suppressed property is still semantically applicable, it is safe for an HL7 interface to assume the implicit default value without testing. type ConceptDescriptor alias CD specializes ANY { ST code; UID codeSystem; ST codeSystemName; ST codeSystemVersion; ST displayName; ED originalText; SET<CD> translation; LIST<CR> qualifier; BL implies(CD x); }; A concept descriptor represents any kind of concept usually by giving a code defined in a code system. A concept descriptor can contain the original text or phrase that served as the basis of the coding and one or more translations into different coding systems. A concept descriptor can also contain qualifiers to describe, e.g., the concept of a "left foot" as a postcoordinated term built from the primary code "FOOT" and the qualifier "LEFT". In cases of an exceptional value, the concept descriptor need not contain a code but only the original text describing that concept. The concept descriptor is mostly used in one of its restricted or 'profiled' forms, CS, CE, CV. Use of the full concept descriptor data type is not common. It requires a conscious decision and documented rationale. In all other cases, one of the restrictions shall be used. The advantage of the concept descriptor data type is its expressiveness, however, if all of its features, such as coding exceptions, text, translations and qualifiers are used at all times, implementation and use become very difficult and unsafe. Therefore, the type is most often used in a restricted form with reduced features. All restrictions constrain certain properties of the . Properties may be constrained to the extent that only one value may be allowed for that property, in which case mentioning the property becomes redundant. Constraining a property to one value is referred to as suppressing that property. Although, conceptually a suppressed property is still semantically applicable, it is safe for an HL7 interface to assume the implicit default value without testing. type ConceptDescriptor alias CD specializes ANY { ST code; UID codeSystem; ST codeSystemName; ST codeSystemVersion; ST displayName; ED originalText; SET<CD> translation; LIST<CR> qualifier; BL implies(CD x); }; A concept descriptor represents any kind of concept usually by giving a code defined in a code system. A concept descriptor can contain the original text or phrase that served as the basis of the coding and one or more translations into different coding systems. A concept descriptor can also contain qualifiers to describe, e.g., the concept of a "left foot" as a postcoordinated term built from the primary code "FOOT" and the qualifier "LEFT". In cases of an exceptional value, the concept descriptor need not contain a code but only the original text describing that concept. The concept descriptor is mostly used in one of its restricted or 'profiled' forms, CS, CE, CV. Use of the full concept descriptor data type is not common. It requires a conscious decision and documented rationale. In all other cases, one of the restrictions shall be used. The advantage of the concept descriptor data type is its expressiveness, however, if all of its features, such as coding exceptions, text, translations and qualifiers are used at all times, implementation and use become very difficult and unsafe. Therefore, the type is most often used in a restricted form with reduced features. All restrictions constrain certain properties of the . Properties may be constrained to the extent that only one value may be allowed for that property, in which case mentioning the property becomes redundant. Constraining a property to one value is referred to as suppressing that property. Although, conceptually a suppressed property is still semantically applicable, it is safe for an HL7 interface to assume the implicit default value without testing. type ConceptDescriptor alias CD specializes ANY { ST code; UID codeSystem; ST codeSystemName; ST codeSystemVersion; ST displayName; ED originalText; SET<CD> translation; LIST<CR> qualifier; BL implies(CD x); }; A concept descriptor represents any kind of concept usually by giving a code defined in a code system. A concept descriptor can contain the original text or phrase that served as the basis of the coding and one or more translations into different coding systems. A concept descriptor can also contain qualifiers to describe, e.g., the concept of a "left foot" as a postcoordinated term built from the primary code "FOOT" and the qualifier "LEFT". In cases of an exceptional value, the concept descriptor need not contain a code but only the original text describing that concept. The concept descriptor is mostly used in one of its restricted or 'profiled' forms, CS, CE, CV. Use of the full concept descriptor data type is not common. It requires a conscious decision and documented rationale. In all other cases, one of the restrictions shall be used. The advantage of the concept descriptor data type is its expressiveness, however, if all of its features, such as coding exceptions, text, translations and qualifiers are used at all times, implementation and use become very difficult and unsafe. Therefore, the type is most often used in a restricted form with reduced features. All restrictions constrain certain properties of the . Properties may be constrained to the extent that only one value may be allowed for that property, in which case mentioning the property becomes redundant. Constraining a property to one value is referred to as suppressing that property. Although, conceptually a suppressed property is still semantically applicable, it is safe for an HL7 interface to assume the implicit default value without testing. type ConceptDescriptor alias CD specializes ANY { ST code; UID codeSystem; ST codeSystemName; ST codeSystemVersion; ST displayName; ED originalText; SET<CD> translation; LIST<CR> qualifier; BL implies(CD x); }; A concept descriptor represents any kind of concept usually by giving a code defined in a code system. A concept descriptor can contain the original text or phrase that served as the basis of the coding and one or more translations into different coding systems. A concept descriptor can also contain qualifiers to describe, e.g., the concept of a "left foot" as a postcoordinated term built from the primary code "FOOT" and the qualifier "LEFT". In cases of an exceptional value, the concept descriptor need not contain a code but only the original text describing that concept. The concept descriptor is mostly used in one of its restricted or 'profiled' forms, CS, CE, CV. Use of the full concept descriptor data type is not common. It requires a conscious decision and documented rationale. In all other cases, one of the restrictions shall be used. The advantage of the concept descriptor data type is its expressiveness, however, if all of its features, such as coding exceptions, text, translations and qualifiers are used at all times, implementation and use become very difficult and unsafe. Therefore, the type is most often used in a restricted form with reduced features. All restrictions constrain certain properties of the . Properties may be constrained to the extent that only one value may be allowed for that property, in which case mentioning the property becomes redundant. Constraining a property to one value is referred to as suppressing that property. Although, conceptually a suppressed property is still semantically applicable, it is safe for an HL7 interface to assume the implicit default value without testing. type ConceptDescriptor alias CD specializes ANY { ST code; UID codeSystem; ST codeSystemName; ST codeSystemVersion; ST displayName; ED originalText; SET<CD> translation; LIST<CR> qualifier; BL implies(CD x); }; A concept descriptor represents any kind of concept usually by giving a code defined in a code system. A concept descriptor can contain the original text or phrase that served as the basis of the coding and one or more translations into different coding systems. A concept descriptor can also contain qualifiers to describe, e.g., the concept of a "left foot" as a postcoordinated term built from the primary code "FOOT" and the qualifier "LEFT". In cases of an exceptional value, the concept descriptor need not contain a code but only the original text describing that concept. The concept descriptor is mostly used in one of its restricted or 'profiled' forms, CS, CE, CV. Use of the full concept descriptor data type is not common. It requires a conscious decision and documented rationale. In all other cases, one of the restrictions shall be used. The advantage of the concept descriptor data type is its expressiveness, however, if all of its features, such as coding exceptions, text, translations and qualifiers are used at all times, implementation and use become very difficult and unsafe. Therefore, the type is most often used in a restricted form with reduced features. All restrictions constrain certain properties of the . Properties may be constrained to the extent that only one value may be allowed for that property, in which case mentioning the property becomes redundant. Constraining a property to one value is referred to as suppressing that property. Although, conceptually a suppressed property is still semantically applicable, it is safe for an HL7 interface to assume the implicit default value without testing. type ConceptDescriptor alias CD specializes ANY { ST code; UID codeSystem; ST codeSystemName; ST codeSystemVersion; ST displayName; ED originalText; SET<CD> translation; LIST<CR> qualifier; BL implies(CD x); }; A concept descriptor represents any kind of concept usually by giving a code defined in a code system. A concept descriptor can contain the original text or phrase that served as the basis of the coding and one or more translations into different coding systems. A concept descriptor can also contain qualifiers to describe, e.g., the concept of a "left foot" as a postcoordinated term built from the primary code "FOOT" and the qualifier "LEFT". In cases of an exceptional value, the concept descriptor need not contain a code but only the original text describing that concept. The concept descriptor is mostly used in one of its restricted or 'profiled' forms, CS, CE, CV. Use of the full concept descriptor data type is not common. It requires a conscious decision and documented rationale. In all other cases, one of the restrictions shall be used. The advantage of the concept descriptor data type is its expressiveness, however, if all of its features, such as coding exceptions, text, translations and qualifiers are used at all times, implementation and use become very difficult and unsafe. Therefore, the type is most often used in a restricted form with reduced features. All restrictions constrain certain properties of the . Properties may be constrained to the extent that only one value may be allowed for that property, in which case mentioning the property becomes redundant. Constraining a property to one value is referred to as suppressing that property. Although, conceptually a suppressed property is still semantically applicable, it is safe for an HL7 interface to assume the implicit default value without testing. type ConceptDescriptor alias CD specializes ANY { ST code; UID codeSystem; ST codeSystemName; ST codeSystemVersion; ST displayName; ED originalText; SET<CD> translation; LIST<CR> qualifier; BL implies(CD x); }; A concept descriptor represents any kind of concept usually by giving a code defined in a code system. A concept descriptor can contain the original text or phrase that served as the basis of the coding and one or more translations into different coding systems. A concept descriptor can also contain qualifiers to describe, e.g., the concept of a "left foot" as a postcoordinated term built from the primary code "FOOT" and the qualifier "LEFT". In cases of an exceptional value, the concept descriptor need not contain a code but only the original text describing that concept. The concept descriptor is mostly used in one of its restricted or 'profiled' forms, CS, CE, CV. Use of the full concept descriptor data type is not common. It requires a conscious decision and documented rationale. In all other cases, one of the restrictions shall be used. The advantage of the concept descriptor data type is its expressiveness, however, if all of its features, such as coding exceptions, text, translations and qualifiers are used at all times, implementation and use become very difficult and unsafe. Therefore, the type is most often used in a restricted form with reduced features. All restrictions constrain certain properties of the . Properties may be constrained to the extent that only one value may be allowed for that property, in which case mentioning the property becomes redundant. Constraining a property to one value is referred to as suppressing that property. Although, conceptually a suppressed property is still semantically applicable, it is safe for an HL7 interface to assume the implicit default value without testing. type ConceptDescriptor alias CD specializes ANY { ST code; UID codeSystem; ST codeSystemName; ST codeSystemVersion; ST displayName; ED originalText; SET<CD> translation; LIST<CR> qualifier; BL implies(CD x); }; A concept descriptor represents any kind of concept usually by giving a code defined in a code system. A concept descriptor can contain the original text or phrase that served as the basis of the coding and one or more translations into different coding systems. A concept descriptor can also contain qualifiers to describe, e.g., the concept of a "left foot" as a postcoordinated term built from the primary code "FOOT" and the qualifier "LEFT". In cases of an exceptional value, the concept descriptor need not contain a code but only the original text describing that concept. The concept descriptor is mostly used in one of its restricted or 'profiled' forms, CS, CE, CV. Use of the full concept descriptor data type is not common. It requires a conscious decision and documented rationale. In all other cases, one of the restrictions shall be used. The advantage of the concept descriptor data type is its expressiveness, however, if all of its features, such as coding exceptions, text, translations and qualifiers are used at all times, implementation and use become very difficult and unsafe. Therefore, the type is most often used in a restricted form with reduced features. All restrictions constrain certain properties of the . Properties may be constrained to the extent that only one value may be allowed for that property, in which case mentioning the property becomes redundant. Constraining a property to one value is referred to as suppressing that property. Although, conceptually a suppressed property is still semantically applicable, it is safe for an HL7 interface to assume the implicit default value without testing. type ConceptDescriptor alias CD specializes ANY { ST code; UID codeSystem; ST codeSystemName; ST codeSystemVersion; ST displayName; ED originalText; SET<CD> translation; LIST<CR> qualifier; BL implies(CD x); }; A concept descriptor represents any kind of concept usually by giving a code defined in a code system. A concept descriptor can contain the original text or phrase that served as the basis of the coding and one or more translations into different coding systems. A concept descriptor can also contain qualifiers to describe, e.g., the concept of a "left foot" as a postcoordinated term built from the primary code "FOOT" and the qualifier "LEFT". In cases of an exceptional value, the concept descriptor need not contain a code but only the original text describing that concept. The concept descriptor is mostly used in one of its restricted or 'profiled' forms, CS, CE, CV. Use of the full concept descriptor data type is not common. It requires a conscious decision and documented rationale. In all other cases, one of the restrictions shall be used. The advantage of the concept descriptor data type is its expressiveness, however, if all of its features, such as coding exceptions, text, translations and qualifiers are used at all times, implementation and use become very difficult and unsafe. Therefore, the type is most often used in a restricted form with reduced features. All restrictions constrain certain properties of the . Properties may be constrained to the extent that only one value may be allowed for that property, in which case mentioning the property becomes redundant. Constraining a property to one value is referred to as suppressing that property. Although, conceptually a suppressed property is still semantically applicable, it is safe for an HL7 interface to assume the implicit default value without testing. type ConceptDescriptor alias CD specializes ANY { ST code; UID codeSystem; ST codeSystemName; ST codeSystemVersion; ST displayName; ED originalText; SET<CD> translation; LIST<CR> qualifier; BL implies(CD x); }; A concept descriptor represents any kind of concept usually by giving a code defined in a code system. A concept descriptor can contain the original text or phrase that served as the basis of the coding and one or more translations into different coding systems. A concept descriptor can also contain qualifiers to describe, e.g., the concept of a "left foot" as a postcoordinated term built from the primary code "FOOT" and the qualifier "LEFT". In cases of an exceptional value, the concept descriptor need not contain a code but only the original text describing that concept. The concept descriptor is mostly used in one of its restricted or 'profiled' forms, CS, CE, CV. Use of the full concept descriptor data type is not common. It requires a conscious decision and documented rationale. In all other cases, one of the restrictions shall be used. The advantage of the concept descriptor data type is its expressiveness, however, if all of its features, such as coding exceptions, text, translations and qualifiers are used at all times, implementation and use become very difficult and unsafe. Therefore, the type is most often used in a restricted form with reduced features. All restrictions constrain certain properties of the . Properties may be constrained to the extent that only one value may be allowed for that property, in which case mentioning the property becomes redundant. Constraining a property to one value is referred to as suppressing that property. Although, conceptually a suppressed property is still semantically applicable, it is safe for an HL7 interface to assume the implicit default value without testing. type ConceptDescriptor alias CD specializes ANY { ST code; UID codeSystem; ST codeSystemName; ST codeSystemVersion; ST displayName; ED originalText; SET<CD> translation; LIST<CR> qualifier; BL implies(CD x); }; CR (ConceptRole) A concept qualifier code with optionally named role. Both qualifier role and value codes must be defined by the coding system of the CD containing the concept qualifier. For example, if SNOMED RT defines a concept "leg", a role relation "has-laterality", and another concept "left", the concept role relation allows to add the qualifier "has-laterality: left" to a primary code "leg" to construct the meaning "left leg". The use of qualifiers is strictly governed by the code system used. The data type does not permit using code qualifiers with code systems that do not provide for qualifiers (e.g. pre-coordinated systems, such as LOINC, ICD-10 PCS.) protected type ConceptRole alias CR specializes ANY { CV name; CD value; BN inverted; }; A concept qualifier code with optionally named role. Both qualifier role and value codes must be defined by the coding system of the CD containing the concept qualifier. For example, if SNOMED RT defines a concept "leg", a role relation "has-laterality", and another concept "left", the concept role relation allows to add the qualifier "has-laterality: left" to a primary code "leg" to construct the meaning "left leg". The use of qualifiers is strictly governed by the code system used. The data type does not permit using code qualifiers with code systems that do not provide for qualifiers (e.g. pre-coordinated systems, such as LOINC, ICD-10 PCS.) protected type ConceptRole alias CR specializes ANY { CV name; CD value; BN inverted; }; A concept qualifier code with optionally named role. Both qualifier role and value codes must be defined by the coding system of the CD containing the concept qualifier. For example, if SNOMED RT defines a concept "leg", a role relation "has-laterality", and another concept "left", the concept role relation allows to add the qualifier "has-laterality: left" to a primary code "leg" to construct the meaning "left leg". The use of qualifiers is strictly governed by the code system used. The data type does not permit using code qualifiers with code systems that do not provide for qualifiers (e.g. pre-coordinated systems, such as LOINC, ICD-10 PCS.) protected type ConceptRole alias CR specializes ANY { CV name; CD value; BN inverted; }; A concept qualifier code with optionally named role. Both qualifier role and value codes must be defined by the coding system of the CD containing the concept qualifier. For example, if SNOMED RT defines a concept "leg", a role relation "has-laterality", and another concept "left", the concept role relation allows to add the qualifier "has-laterality: left" to a primary code "leg" to construct the meaning "left leg". The use of qualifiers is strictly governed by the code system used. The data type does not permit using code qualifiers with code systems that do not provide for qualifiers (e.g. pre-coordinated systems, such as LOINC, ICD-10 PCS.) protected type ConceptRole alias CR specializes ANY { CV name; CD value; BN inverted; }; CS (CodedSimpleValue) XCoded data in its simplest form, where only the code is not predetermined. The code system and code system version are fixed by the context in which the CS value occurs. CS is used for coded attributes that have a single HL7-defined value set. can only be used in either of the following cases: for a coded attribute which has a single HL7-defined code system, and where code additions to that value set require formal HL7 action (such as harmonization.) Such coded attributes must be assigned the restriction. for a property in this specification that is assigned to a single code system defined either in this specification or defined outside HL7 by a body that has authority over the concept and the maintenance of that code system. For example, since the type subscribes to the MIME design, it trusts IETF to manage the media type. This includes that this specification subscribes to the extension mechanism built into the MIME media type code (e.g., "application/x-myapp"). For values, the designation of the domain qualifier will always be CNE (coded, non-extensible) and the context will determine which HL7 values to use. This is not withstanding the fact that an external referenced domain, such as the IETF MIME media type may include an extension mechanism. These extended MIME type codes would not be considered "extensions" in the sense of violating the CNE provision. The CNE provision is only violated if an attempt is made in using a different code system (by means of the CD.codeSystem property), which is not possible with the data type. type CodedSimpleValue alias CS specializes CV { literal ST; }; XCoded data in its simplest form, where only the code is not predetermined. The code system and code system version are fixed by the context in which the CS value occurs. CS is used for coded attributes that have a single HL7-defined value set. can only be used in either of the following cases: for a coded attribute which has a single HL7-defined code system, and where code additions to that value set require formal HL7 action (such as harmonization.) Such coded attributes must be assigned the restriction. for a property in this specification that is assigned to a single code system defined either in this specification or defined outside HL7 by a body that has authority over the concept and the maintenance of that code system. For example, since the type subscribes to the MIME design, it trusts IETF to manage the media type. This includes that this specification subscribes to the extension mechanism built into the MIME media type code (e.g., "application/x-myapp"). For values, the designation of the domain qualifier will always be CNE (coded, non-extensible) and the context will determine which HL7 values to use. This is not withstanding the fact that an external referenced domain, such as the IETF MIME media type may include an extension mechanism. These extended MIME type codes would not be considered "extensions" in the sense of violating the CNE provision. The CNE provision is only violated if an attempt is made in using a different code system (by means of the CD.codeSystem property), which is not possible with the data type. type CodedSimpleValue alias CS specializes CV { literal ST; }; XCoded data in its simplest form, where only the code is not predetermined. The code system and code system version are fixed by the context in which the CS value occurs. CS is used for coded attributes that have a single HL7-defined value set. can only be used in either of the following cases: for a coded attribute which has a single HL7-defined code system, and where code additions to that value set require formal HL7 action (such as harmonization.) Such coded attributes must be assigned the restriction. for a property in this specification that is assigned to a single code system defined either in this specification or defined outside HL7 by a body that has authority over the concept and the maintenance of that code system. For example, since the type subscribes to the MIME design, it trusts IETF to manage the media type. This includes that this specification subscribes to the extension mechanism built into the MIME media type code (e.g., "application/x-myapp"). For values, the designation of the domain qualifier will always be CNE (coded, non-extensible) and the context will determine which HL7 values to use. This is not withstanding the fact that an external referenced domain, such as the IETF MIME media type may include an extension mechanism. These extended MIME type codes would not be considered "extensions" in the sense of violating the CNE provision. The CNE provision is only violated if an attempt is made in using a different code system (by means of the CD.codeSystem property), which is not possible with the data type. type CodedSimpleValue alias CS specializes CV { literal ST; }; XCoded data in its simplest form, where only the code is not predetermined. The code system and code system version are fixed by the context in which the CS value occurs. CS is used for coded attributes that have a single HL7-defined value set. can only be used in either of the following cases: for a coded attribute which has a single HL7-defined code system, and where code additions to that value set require formal HL7 action (such as harmonization.) Such coded attributes must be assigned the restriction. for a property in this specification that is assigned to a single code system defined either in this specification or defined outside HL7 by a body that has authority over the concept and the maintenance of that code system. For example, since the type subscribes to the MIME design, it trusts IETF to manage the media type. This includes that this specification subscribes to the extension mechanism built into the MIME media type code (e.g., "application/x-myapp"). For values, the designation of the domain qualifier will always be CNE (coded, non-extensible) and the context will determine which HL7 values to use. This is not withstanding the fact that an external referenced domain, such as the IETF MIME media type may include an extension mechanism. These extended MIME type codes would not be considered "extensions" in the sense of violating the CNE provision. The CNE provision is only violated if an attempt is made in using a different code system (by means of the CD.codeSystem property), which is not possible with the data type. type CodedSimpleValue alias CS specializes CV { literal ST; }; XCoded data in its simplest form, where only the code is not predetermined. The code system and code system version are fixed by the context in which the CS value occurs. CS is used for coded attributes that have a single HL7-defined value set. can only be used in either of the following cases: for a coded attribute which has a single HL7-defined code system, and where code additions to that value set require formal HL7 action (such as harmonization.) Such coded attributes must be assigned the restriction. for a property in this specification that is assigned to a single code system defined either in this specification or defined outside HL7 by a body that has authority over the concept and the maintenance of that code system. For example, since the type subscribes to the MIME design, it trusts IETF to manage the media type. This includes that this specification subscribes to the extension mechanism built into the MIME media type code (e.g., "application/x-myapp"). For values, the designation of the domain qualifier will always be CNE (coded, non-extensible) and the context will determine which HL7 values to use. This is not withstanding the fact that an external referenced domain, such as the IETF MIME media type may include an extension mechanism. These extended MIME type codes would not be considered "extensions" in the sense of violating the CNE provision. The CNE provision is only violated if an attempt is made in using a different code system (by means of the CD.codeSystem property), which is not possible with the data type. type CodedSimpleValue alias CS specializes CV { literal ST; }; XCoded data in its simplest form, where only the code is not predetermined. The code system and code system version are fixed by the context in which the CS value occurs. CS is used for coded attributes that have a single HL7-defined value set. can only be used in either of the following cases: for a coded attribute which has a single HL7-defined code system, and where code additions to that value set require formal HL7 action (such as harmonization.) Such coded attributes must be assigned the restriction. for a property in this specification that is assigned to a single code system defined either in this specification or defined outside HL7 by a body that has authority over the concept and the maintenance of that code system. For example, since the type subscribes to the MIME design, it trusts IETF to manage the media type. This includes that this specification subscribes to the extension mechanism built into the MIME media type code (e.g., "application/x-myapp"). For values, the designation of the domain qualifier will always be CNE (coded, non-extensible) and the context will determine which HL7 values to use. This is not withstanding the fact that an external referenced domain, such as the IETF MIME media type may include an extension mechanism. These extended MIME type codes would not be considered "extensions" in the sense of violating the CNE provision. The CNE provision is only violated if an attempt is made in using a different code system (by means of the CD.codeSystem property), which is not possible with the data type. type CodedSimpleValue alias CS specializes CV { literal ST; }; XCoded data in its simplest form, where only the code is not predetermined. The code system and code system version are fixed by the context in which the CS value occurs. CS is used for coded attributes that have a single HL7-defined value set. can only be used in either of the following cases: for a coded attribute which has a single HL7-defined code system, and where code additions to that value set require formal HL7 action (such as harmonization.) Such coded attributes must be assigned the restriction. for a property in this specification that is assigned to a single code system defined either in this specification or defined outside HL7 by a body that has authority over the concept and the maintenance of that code system. For example, since the type subscribes to the MIME design, it trusts IETF to manage the media type. This includes that this specification subscribes to the extension mechanism built into the MIME media type code (e.g., "application/x-myapp"). For values, the designation of the domain qualifier will always be CNE (coded, non-extensible) and the context will determine which HL7 values to use. This is not withstanding the fact that an external referenced domain, such as the IETF MIME media type may include an extension mechanism. These extended MIME type codes would not be considered "extensions" in the sense of violating the CNE provision. The CNE provision is only violated if an attempt is made in using a different code system (by means of the CD.codeSystem property), which is not possible with the data type. type CodedSimpleValue alias CS specializes CV { literal ST; }; XCoded data in its simplest form, where only the code is not predetermined. The code system and code system version are fixed by the context in which the CS value occurs. CS is used for coded attributes that have a single HL7-defined value set. can only be used in either of the following cases: for a coded attribute which has a single HL7-defined code system, and where code additions to that value set require formal HL7 action (such as harmonization.) Such coded attributes must be assigned the restriction. for a property in this specification that is assigned to a single code system defined either in this specification or defined outside HL7 by a body that has authority over the concept and the maintenance of that code system. For example, since the type subscribes to the MIME design, it trusts IETF to manage the media type. This includes that this specification subscribes to the extension mechanism built into the MIME media type code (e.g., "application/x-myapp"). For values, the designation of the domain qualifier will always be CNE (coded, non-extensible) and the context will determine which HL7 values to use. This is not withstanding the fact that an external referenced domain, such as the IETF MIME media type may include an extension mechanism. These extended MIME type codes would not be considered "extensions" in the sense of violating the CNE provision. The CNE provision is only violated if an attempt is made in using a different code system (by means of the CD.codeSystem property), which is not possible with the data type. type CodedSimpleValue alias CS specializes CV { literal ST; }; XCoded data in its simplest form, where only the code is not predetermined. The code system and code system version are fixed by the context in which the CS value occurs. CS is used for coded attributes that have a single HL7-defined value set. can only be used in either of the following cases: for a coded attribute which has a single HL7-defined code system, and where code additions to that value set require formal HL7 action (such as harmonization.) Such coded attributes must be assigned the restriction. for a property in this specification that is assigned to a single code system defined either in this specification or defined outside HL7 by a body that has authority over the concept and the maintenance of that code system. For example, since the type subscribes to the MIME design, it trusts IETF to manage the media type. This includes that this specification subscribes to the extension mechanism built into the MIME media type code (e.g., "application/x-myapp"). For values, the designation of the domain qualifier will always be CNE (coded, non-extensible) and the context will determine which HL7 values to use. This is not withstanding the fact that an external referenced domain, such as the IETF MIME media type may include an extension mechanism. These extended MIME type codes would not be considered "extensions" in the sense of violating the CNE provision. The CNE provision is only violated if an attempt is made in using a different code system (by means of the CD.codeSystem property), which is not possible with the data type. type CodedSimpleValue alias CS specializes CV { literal ST; }; XCoded data in its simplest form, where only the code is not predetermined. The code system and code system version are fixed by the context in which the CS value occurs. CS is used for coded attributes that have a single HL7-defined value set. can only be used in either of the following cases: for a coded attribute which has a single HL7-defined code system, and where code additions to that value set require formal HL7 action (such as harmonization.) Such coded attributes must be assigned the restriction. for a property in this specification that is assigned to a single code system defined either in this specification or defined outside HL7 by a body that has authority over the concept and the maintenance of that code system. For example, since the type subscribes to the MIME design, it trusts IETF to manage the media type. This includes that this specification subscribes to the extension mechanism built into the MIME media type code (e.g., "application/x-myapp"). For values, the designation of the domain qualifier will always be CNE (coded, non-extensible) and the context will determine which HL7 values to use. This is not withstanding the fact that an external referenced domain, such as the IETF MIME media type may include an extension mechanism. These extended MIME type codes would not be considered "extensions" in the sense of violating the CNE provision. The CNE provision is only violated if an attempt is made in using a different code system (by means of the CD.codeSystem property), which is not possible with the data type. type CodedSimpleValue alias CS specializes CV { literal ST; }; CV (CodedValue) Coded data, specifying only a code, code system, and optionally display name and original text. Used only as the data type for other data types' properties. This type is used when any reasonable use case will require only a single code value to be sent. Thus, it should not be used in circumstances where multiple alternative codes for a given value are desired. This type may be used with both the CNE (coded, non-extensible) and the CWE (coded, with extensibility) domain qualifiers. protected type CodedValue alias CV specializes CE; Coded data, specifying only a code, code system, and optionally display name and original text. Used only as the data type for other data types' properties. This type is used when any reasonable use case will require only a single code value to be sent. Thus, it should not be used in circumstances where multiple alternative codes for a given value are desired. This type may be used with both the CNE (coded, non-extensible) and the CWE (coded, with extensibility) domain qualifiers. protected type CodedValue alias CV specializes CE; Coded data, specifying only a code, code system, and optionally display name and original text. Used only as the data type for other data types' properties. This type is used when any reasonable use case will require only a single code value to be sent. Thus, it should not be used in circumstances where multiple alternative codes for a given value are desired. This type may be used with both the CNE (coded, non-extensible) and the CWE (coded, with extensibility) domain qualifiers. protected type CodedValue alias CV specializes CE; Coded data, specifying only a code, code system, and optionally display name and original text. Used only as the data type for other data types' properties. This type is used when any reasonable use case will require only a single code value to be sent. Thus, it should not be used in circumstances where multiple alternative codes for a given value are desired. This type may be used with both the CNE (coded, non-extensible) and the CWE (coded, with extensibility) domain qualifiers. protected type CodedValue alias CV specializes CE; Coded data, specifying only a code, code system, and optionally display name and original text. Used only as the data type for other data types' properties. This type is used when any reasonable use case will require only a single code value to be sent. Thus, it should not be used in circumstances where multiple alternative codes for a given value are desired. This type may be used with both the CNE (coded, non-extensible) and the CWE (coded, with extensibility) domain qualifiers. protected type CodedValue alias CV specializes CE; Coded data, specifying only a code, code system, and optionally display name and original text. Used only as the data type for other data types' properties. This type is used when any reasonable use case will require only a single code value to be sent. Thus, it should not be used in circumstances where multiple alternative codes for a given value are desired. This type may be used with both the CNE (coded, non-extensible) and the CWE (coded, with extensibility) domain qualifiers. protected type CodedValue alias CV specializes CE; Coded data, specifying only a code, code system, and optionally display name and original text. Used only as the data type for other data types' properties. This type is used when any reasonable use case will require only a single code value to be sent. Thus, it should not be used in circumstances where multiple alternative codes for a given value are desired. This type may be used with both the CNE (coded, non-extensible) and the CWE (coded, with extensibility) domain qualifiers. protected type CodedValue alias CV specializes CE; Coded data, specifying only a code, code system, and optionally display name and original text. Used only as the data type for other data types' properties. This type is used when any reasonable use case will require only a single code value to be sent. Thus, it should not be used in circumstances where multiple alternative codes for a given value are desired. This type may be used with both the CNE (coded, non-extensible) and the CWE (coded, with extensibility) domain qualifiers. protected type CodedValue alias CV specializes CE; Coded data, specifying only a code, code system, and optionally display name and original text. Used only as the data type for other data types' properties. This type is used when any reasonable use case will require only a single code value to be sent. Thus, it should not be used in circumstances where multiple alternative codes for a given value are desired. This type may be used with both the CNE (coded, non-extensible) and the CWE (coded, with extensibility) domain qualifiers. protected type CodedValue alias CV specializes CE; CO (CodedOrdinal) Coded data, where the domain from which the codeset comes is ordered. The Coded Ordinal data type adds semantics related to ordering so that models that make use of such domains may introduce model elements that involve statements about the order of the terms in a domain. The relative order of this type's values need not be independently obvious in their literal representation. It is expected that an application will look up the ordering of these values from some table. type CodedOrdinal alias CO specializes CV { BL lessOrEqual(CO o); BL lessThan(CO o); BL greaterThan(CO o); BL greaterOrEqual(CO o); }; Coded data, where the domain from which the codeset comes is ordered. The Coded Ordinal data type adds semantics related to ordering so that models that make use of such domains may introduce model elements that involve statements about the order of the terms in a domain. The relative order of this type's values need not be independently obvious in their literal representation. It is expected that an application will look up the ordering of these values from some table. type CodedOrdinal alias CO specializes CV { BL lessOrEqual(CO o); BL lessThan(CO o); BL greaterThan(CO o); BL greaterOrEqual(CO o); }; Coded data, where the domain from which the codeset comes is ordered. The Coded Ordinal data type adds semantics related to ordering so that models that make use of such domains may introduce model elements that involve statements about the order of the terms in a domain. The relative order of this type's values need not be independently obvious in their literal representation. It is expected that an application will look up the ordering of these values from some table. type CodedOrdinal alias CO specializes CV { BL lessOrEqual(CO o); BL lessThan(CO o); BL greaterThan(CO o); BL greaterOrEqual(CO o); }; Coded data, where the domain from which the codeset comes is ordered. The Coded Ordinal data type adds semantics related to ordering so that models that make use of such domains may introduce model elements that involve statements about the order of the terms in a domain. The relative order of this type's values need not be independently obvious in their literal representation. It is expected that an application will look up the ordering of these values from some table. type CodedOrdinal alias CO specializes CV { BL lessOrEqual(CO o); BL lessThan(CO o); BL greaterThan(CO o); BL greaterOrEqual(CO o); }; Coded data, where the domain from which the codeset comes is ordered. The Coded Ordinal data type adds semantics related to ordering so that models that make use of such domains may introduce model elements that involve statements about the order of the terms in a domain. The relative order of this type's values need not be independently obvious in their literal representation. It is expected that an application will look up the ordering of these values from some table. type CodedOrdinal alias CO specializes CV { BL lessOrEqual(CO o); BL lessThan(CO o); BL greaterThan(CO o); BL greaterOrEqual(CO o); }; CE (CodedWithEquivalents) Coded data that consists of a coded value (CV) and, optionally, coded value(s) from other coding systems that identify the same concept. Used when alternative codes may exist. The type is used when the use case indicates that alternative codes may exist and where it is useful to communicate these. The type provides for a primary code value, plus a set of alternative or equivalent representations. type CodedWithEquivalents alias CE specializes CD; Coded data that consists of a coded value (CV) and, optionally, coded value(s) from other coding systems that identify the same concept. Used when alternative codes may exist. The type is used when the use case indicates that alternative codes may exist and where it is useful to communicate these. The type provides for a primary code value, plus a set of alternative or equivalent representations. type CodedWithEquivalents alias CE specializes CD; Coded data that consists of a coded value (CV) and, optionally, coded value(s) from other coding systems that identify the same concept. Used when alternative codes may exist. The type is used when the use case indicates that alternative codes may exist and where it is useful to communicate these. The type provides for a primary code value, plus a set of alternative or equivalent representations. type CodedWithEquivalents alias CE specializes CD; Coded data that consists of a coded value (CV) and, optionally, coded value(s) from other coding systems that identify the same concept. Used when alternative codes may exist. The type is used when the use case indicates that alternative codes may exist and where it is useful to communicate these. The type provides for a primary code value, plus a set of alternative or equivalent representations. type CodedWithEquivalents alias CE specializes CD; Coded data that consists of a coded value (CV) and, optionally, coded value(s) from other coding systems that identify the same concept. Used when alternative codes may exist. The type is used when the use case indicates that alternative codes may exist and where it is useful to communicate these. The type provides for a primary code value, plus a set of alternative or equivalent representations. type CodedWithEquivalents alias CE specializes CD; Coded data that consists of a coded value (CV) and, optionally, coded value(s) from other coding systems that identify the same concept. Used when alternative codes may exist. The type is used when the use case indicates that alternative codes may exist and where it is useful to communicate these. The type provides for a primary code value, plus a set of alternative or equivalent representations. type CodedWithEquivalents alias CE specializes CD; Coded data that consists of a coded value (CV) and, optionally, coded value(s) from other coding systems that identify the same concept. Used when alternative codes may exist. The type is used when the use case indicates that alternative codes may exist and where it is useful to communicate these. The type provides for a primary code value, plus a set of alternative or equivalent representations. type CodedWithEquivalents alias CE specializes CD; Coded data that consists of a coded value (CV) and, optionally, coded value(s) from other coding systems that identify the same concept. Used when alternative codes may exist. The type is used when the use case indicates that alternative codes may exist and where it is useful to communicate these. The type provides for a primary code value, plus a set of alternative or equivalent representations. type CodedWithEquivalents alias CE specializes CD; Coded data that consists of a coded value (CV) and, optionally, coded value(s) from other coding systems that identify the same concept. Used when alternative codes may exist. The type is used when the use case indicates that alternative codes may exist and where it is useful to communicate these. The type provides for a primary code value, plus a set of alternative or equivalent representations. type CodedWithEquivalents alias CE specializes CD; SC (CharacterStringWithCode) A character string that optionally may have a code attached. The text must always be present if a code is present. The code is often a local code. This data type is used in cases where coding is exceptional (e.g., user text messages are essentially text messages, and a printable message is the important content. Yet, sometimes messages come from a catalog of canned messages, which the SC allows to reference. type CharacterStringWithCode alias SC specializes ST { CE code; }; A character string that optionally may have a code attached. The text must always be present if a code is present. The code is often a local code. This data type is used in cases where coding is exceptional (e.g., user text messages are essentially text messages, and a printable message is the important content. Yet, sometimes messages come from a catalog of canned messages, which the SC allows to reference. type CharacterStringWithCode alias SC specializes ST { CE code; }; UID (UniqueIdentifierString) A unique identifier string is a character string which identifies an object in a globally unique and timeless manner. The allowable formats and values and procedures of this data type are strictly controlled by HL7. At this time, user-assigned identifiers may be certain character representations of ISO Object Identifiers (OID) and DCE Universally Unique Identifiers (UUID). HL7 also reserves the right to assign other forms of UIDs, such as mnemonic identifiers for code systems. The sole purpose of the UID is to be a globally and timelessly unique identifier. The form of the UID, whether it is an OID, an UUID or any other form is entirely irrelevant. As far as HL7 is concerned, the only thing one can do with a UID is denote to the object for which it stands. Comparison of UIDs is literal, i.e. if two UIDs are literally identical, they are assumed to denote to the same object. If two UIDs are not literally identical they may not denote to the same object. No difference in semantics is recognized between the different allowed forms of the UID. The different forms are not distinguished by a component within or aside from the identifier string itself. Even though this specification recognizes no semantic difference between the different forms of the unique identifier forms, there are differences of how these identifiers are built and managed, which is the sole reason to define subtypes to the UID for each of the variants. protected type UniqueIdentifierString alias UID specializes ST; OID (ObjectIdentifier) A globally unique string representing an ISO Object Identifier (OID) in a form that consists only of numbers and dots (e.g., "2.16.840.1.113883.3.1"). According to ISO, OIDs are paths in a tree structure, with the left-most number representing the root and the right-most number representing a leaf. Each branch under the root corresponds to an assigning authority. Each of these assigning authorities may, in turn, designate its own set of assigning authorities that work under its auspices, and so on down the line. Eventually, one of these authorities assigns a unique (to it as an assigning authority) number that corresponds to a leaf node on the tree. The leaf may represent an assigning authority (in which case the root OID identifies the authority), or an instance of an object. An assigning authority owns a namespace, consisting of its sub-tree. OIDs are the preferred scheme for unique identifiers. OIDs should always be used except if one of the inclusion criteria for other schemes apply. ISO/IEC 8824:1990(E) clause 28 defines the Object Identifier as 28.9 The semantics of an object identifier value are defined by reference to an object identifier tree. An object identifier tree is a tree whose root corresponds to [the ISO/IEC 8824 standard] and whose vertices [i.e. nodes] correspond to administrative authorities responsible for allocating arcs [i.e. branches] from that vertex. Each arc from that tree is labeled by an object identifier component, which is [an integer number]. Each information object to be identified is allocated precisely one vertex (normally a leaf) and no other information object (of the same or a different type) is allocated to that same vertex. Thus an information object is uniquely and unambiguously identified by the sequence of [integer numbers] (object identifier components) labeling the arcs in a path from the root to the vertex allocated to the information object. 28.10 An object identifier value is semantically an ordered list of object identifier component values. Starting with the root of the object identifier tree, each object identifier component value identifies an arc in the object identifier tree. The last object identifier component value identifies an arc leading to a vertex to which an information object has been assigned. It is this information object, which is identified by the object identifier value. [...] According to ISO/IEC 8824 an object identifier is a sequence of object identifier component values, which are integer numbers. These component values are ordered such that the root of the object identifier tree is the head of the list followed by all the arcs down to the leaf representing the information object identified by the OID. The fact that OID specializes < > represents this path of object identifier component values from the root to the leaf. The leaf and "butLeaf" properties take the opposite view. The leaf is the last object identifier component value in the list, and the "butLeaf" property is all of the OID but the leaf. In a sense, the leaf is the identifier value and all of the OID but the leaf refers to the namespace in which the leaf is unique and meaningful. However, what part of the OID is considered value and what is namespace may be viewed differently. In general, any OID component sequence to the left can be considered the namespace in which the rest of the sequence to the right is defined as a meaningful and unique identifier value. The value-property with a namespace OID as its argument represents this point of view. The value/namespace view on ISO object identifiers has important semantic relevance. It represents the notion of identifier value versus identifier assigning authority (= namespace), which is common in healthcare information systems in general, and HL7 v2.x in particular. section-OID.procedures HL7 shall establish an OID registry and assign OIDs in its branch for HL7 users and vendors upon their request. HL7 shall also assign OIDs to public identifier-assigning authorities both U.S. nationally (e.g., the U.S. State driver license bureaus, U.S. Social Security Administration, HIPAA Provider ID registry, etc.) and internationally (e.g., other countries Social Security Administrations, Citizen ID registries, etc.) The HL7 registered OIDs must be used for these organizations, regardless whether these organizations have other OIDs assigned from other sources. When assigning OIDs to third parties or entities, HL7 shall investigate whether an OID is already assigned for such entities through other sources. It this is the case, HL7 shall record such OID in a catalog, but HL7 shall not assign a duplicate OID in the HL7 branch. If possible, HL7 shall notify a third party when an OID is being assigned for that party in the HL7 branch. Though HL7 shall exercise diligence before assigning an OID in the HL7 branch to third parties, given the lack of a global OID registry mechanism, one cannot make absolutely certain that there is no preexisting OID assignment for such third-party entity. Also, a duplicate assignment can happen in the future through another source. If such cases of supplicate assignment become known to HL7, HL7 shall make efforts to resolve this situation. For continued interoperability in the meantime, the HL7 assigned OID shall be the preferred OID used. While most owners of an OID will "design" their namespace sub-tree in some meaningful way, there is no way to generally infer any meaning on the parts of an OID. HL7 does not standardize or require any namespace sub-structure. An OID owner, or anyone having knowledge about the logical structure of part of an OID, may still use that knowledge to infer information about the associated object; however, the techniques cannot be generalized. Example for a tree of ISO object identifiers. HL7's OID is 2.16.840.1.113883. An HL7 interface must not rely on any knowledge about the substructure of an OID for which it cannot control the assignment policies. protected type ObjectIdentifier alias OID specializes UID, LIST<INT> { INT leaf; OID butLeaf; OID value(OID namespace); literal ST; }; A globally unique string representing an ISO Object Identifier (OID) in a form that consists only of numbers and dots (e.g., "2.16.840.1.113883.3.1"). According to ISO, OIDs are paths in a tree structure, with the left-most number representing the root and the right-most number representing a leaf. Each branch under the root corresponds to an assigning authority. Each of these assigning authorities may, in turn, designate its own set of assigning authorities that work under its auspices, and so on down the line. Eventually, one of these authorities assigns a unique (to it as an assigning authority) number that corresponds to a leaf node on the tree. The leaf may represent an assigning authority (in which case the root OID identifies the authority), or an instance of an object. An assigning authority owns a namespace, consisting of its sub-tree. OIDs are the preferred scheme for unique identifiers. OIDs should always be used except if one of the inclusion criteria for other schemes apply. ISO/IEC 8824:1990(E) clause 28 defines the Object Identifier as 28.9 The semantics of an object identifier value are defined by reference to an object identifier tree. An object identifier tree is a tree whose root corresponds to [the ISO/IEC 8824 standard] and whose vertices [i.e. nodes] correspond to administrative authorities responsible for allocating arcs [i.e. branches] from that vertex. Each arc from that tree is labeled by an object identifier component, which is [an integer number]. Each information object to be identified is allocated precisely one vertex (normally a leaf) and no other information object (of the same or a different type) is allocated to that same vertex. Thus an information object is uniquely and unambiguously identified by the sequence of [integer numbers] (object identifier components) labeling the arcs in a path from the root to the vertex allocated to the information object. 28.10 An object identifier value is semantically an ordered list of object identifier component values. Starting with the root of the object identifier tree, each object identifier component value identifies an arc in the object identifier tree. The last object identifier component value identifies an arc leading to a vertex to which an information object has been assigned. It is this information object, which is identified by the object identifier value. [...] According to ISO/IEC 8824 an object identifier is a sequence of object identifier component values, which are integer numbers. These component values are ordered such that the root of the object identifier tree is the head of the list followed by all the arcs down to the leaf representing the information object identified by the OID. The fact that OID specializes < > represents this path of object identifier component values from the root to the leaf. The leaf and "butLeaf" properties take the opposite view. The leaf is the last object identifier component value in the list, and the "butLeaf" property is all of the OID but the leaf. In a sense, the leaf is the identifier value and all of the OID but the leaf refers to the namespace in which the leaf is unique and meaningful. However, what part of the OID is considered value and what is namespace may be viewed differently. In general, any OID component sequence to the left can be considered the namespace in which the rest of the sequence to the right is defined as a meaningful and unique identifier value. The value-property with a namespace OID as its argument represents this point of view. The value/namespace view on ISO object identifiers has important semantic relevance. It represents the notion of identifier value versus identifier assigning authority (= namespace), which is common in healthcare information systems in general, and HL7 v2.x in particular. section-OID.procedures HL7 shall establish an OID registry and assign OIDs in its branch for HL7 users and vendors upon their request. HL7 shall also assign OIDs to public identifier-assigning authorities both U.S. nationally (e.g., the U.S. State driver license bureaus, U.S. Social Security Administration, HIPAA Provider ID registry, etc.) and internationally (e.g., other countries Social Security Administrations, Citizen ID registries, etc.) The HL7 registered OIDs must be used for these organizations, regardless whether these organizations have other OIDs assigned from other sources. When assigning OIDs to third parties or entities, HL7 shall investigate whether an OID is already assigned for such entities through other sources. It this is the case, HL7 shall record such OID in a catalog, but HL7 shall not assign a duplicate OID in the HL7 branch. If possible, HL7 shall notify a third party when an OID is being assigned for that party in the HL7 branch. Though HL7 shall exercise diligence before assigning an OID in the HL7 branch to third parties, given the lack of a global OID registry mechanism, one cannot make absolutely certain that there is no preexisting OID assignment for such third-party entity. Also, a duplicate assignment can happen in the future through another source. If such cases of supplicate assignment become known to HL7, HL7 shall make efforts to resolve this situation. For continued interoperability in the meantime, the HL7 assigned OID shall be the preferred OID used. While most owners of an OID will "design" their namespace sub-tree in some meaningful way, there is no way to generally infer any meaning on the parts of an OID. HL7 does not standardize or require any namespace sub-structure. An OID owner, or anyone having knowledge about the logical structure of part of an OID, may still use that knowledge to infer information about the associated object; however, the techniques cannot be generalized. Example for a tree of ISO object identifiers. HL7's OID is 2.16.840.1.113883. An HL7 interface must not rely on any knowledge about the substructure of an OID for which it cannot control the assignment policies. protected type ObjectIdentifier alias OID specializes UID, LIST<INT> { INT leaf; OID butLeaf; OID value(OID namespace); literal ST; }; A globally unique string representing an ISO Object Identifier (OID) in a form that consists only of numbers and dots (e.g., "2.16.840.1.113883.3.1"). According to ISO, OIDs are paths in a tree structure, with the left-most number representing the root and the right-most number representing a leaf. Each branch under the root corresponds to an assigning authority. Each of these assigning authorities may, in turn, designate its own set of assigning authorities that work under its auspices, and so on down the line. Eventually, one of these authorities assigns a unique (to it as an assigning authority) number that corresponds to a leaf node on the tree. The leaf may represent an assigning authority (in which case the root OID identifies the authority), or an instance of an object. An assigning authority owns a namespace, consisting of its sub-tree. OIDs are the preferred scheme for unique identifiers. OIDs should always be used except if one of the inclusion criteria for other schemes apply. ISO/IEC 8824:1990(E) clause 28 defines the Object Identifier as 28.9 The semantics of an object identifier value are defined by reference to an object identifier tree. An object identifier tree is a tree whose root corresponds to [the ISO/IEC 8824 standard] and whose vertices [i.e. nodes] correspond to administrative authorities responsible for allocating arcs [i.e. branches] from that vertex. Each arc from that tree is labeled by an object identifier component, which is [an integer number]. Each information object to be identified is allocated precisely one vertex (normally a leaf) and no other information object (of the same or a different type) is allocated to that same vertex. Thus an information object is uniquely and unambiguously identified by the sequence of [integer numbers] (object identifier components) labeling the arcs in a path from the root to the vertex allocated to the information object. 28.10 An object identifier value is semantically an ordered list of object identifier component values. Starting with the root of the object identifier tree, each object identifier component value identifies an arc in the object identifier tree. The last object identifier component value identifies an arc leading to a vertex to which an information object has been assigned. It is this information object, which is identified by the object identifier value. [...] According to ISO/IEC 8824 an object identifier is a sequence of object identifier component values, which are integer numbers. These component values are ordered such that the root of the object identifier tree is the head of the list followed by all the arcs down to the leaf representing the information object identified by the OID. The fact that OID specializes < > represents this path of object identifier component values from the root to the leaf. The leaf and "butLeaf" properties take the opposite view. The leaf is the last object identifier component value in the list, and the "butLeaf" property is all of the OID but the leaf. In a sense, the leaf is the identifier value and all of the OID but the leaf refers to the namespace in which the leaf is unique and meaningful. However, what part of the OID is considered value and what is namespace may be viewed differently. In general, any OID component sequence to the left can be considered the namespace in which the rest of the sequence to the right is defined as a meaningful and unique identifier value. The value-property with a namespace OID as its argument represents this point of view. The value/namespace view on ISO object identifiers has important semantic relevance. It represents the notion of identifier value versus identifier assigning authority (= namespace), which is common in healthcare information systems in general, and HL7 v2.x in particular. section-OID.procedures HL7 shall establish an OID registry and assign OIDs in its branch for HL7 users and vendors upon their request. HL7 shall also assign OIDs to public identifier-assigning authorities both U.S. nationally (e.g., the U.S. State driver license bureaus, U.S. Social Security Administration, HIPAA Provider ID registry, etc.) and internationally (e.g., other countries Social Security Administrations, Citizen ID registries, etc.) The HL7 registered OIDs must be used for these organizations, regardless whether these organizations have other OIDs assigned from other sources. When assigning OIDs to third parties or entities, HL7 shall investigate whether an OID is already assigned for such entities through other sources. It this is the case, HL7 shall record such OID in a catalog, but HL7 shall not assign a duplicate OID in the HL7 branch. If possible, HL7 shall notify a third party when an OID is being assigned for that party in the HL7 branch. Though HL7 shall exercise diligence before assigning an OID in the HL7 branch to third parties, given the lack of a global OID registry mechanism, one cannot make absolutely certain that there is no preexisting OID assignment for such third-party entity. Also, a duplicate assignment can happen in the future through another source. If such cases of supplicate assignment become known to HL7, HL7 shall make efforts to resolve this situation. For continued interoperability in the meantime, the HL7 assigned OID shall be the preferred OID used. While most owners of an OID will "design" their namespace sub-tree in some meaningful way, there is no way to generally infer any meaning on the parts of an OID. HL7 does not standardize or require any namespace sub-structure. An OID owner, or anyone having knowledge about the logical structure of part of an OID, may still use that knowledge to infer information about the associated object; however, the techniques cannot be generalized. Example for a tree of ISO object identifiers. HL7's OID is 2.16.840.1.113883. An HL7 interface must not rely on any knowledge about the substructure of an OID for which it cannot control the assignment policies. protected type ObjectIdentifier alias OID specializes UID, LIST<INT> { INT leaf; OID butLeaf; OID value(OID namespace); literal ST; }; A globally unique string representing an ISO Object Identifier (OID) in a form that consists only of numbers and dots (e.g., "2.16.840.1.113883.3.1"). According to ISO, OIDs are paths in a tree structure, with the left-most number representing the root and the right-most number representing a leaf. Each branch under the root corresponds to an assigning authority. Each of these assigning authorities may, in turn, designate its own set of assigning authorities that work under its auspices, and so on down the line. Eventually, one of these authorities assigns a unique (to it as an assigning authority) number that corresponds to a leaf node on the tree. The leaf may represent an assigning authority (in which case the root OID identifies the authority), or an instance of an object. An assigning authority owns a namespace, consisting of its sub-tree. OIDs are the preferred scheme for unique identifiers. OIDs should always be used except if one of the inclusion criteria for other schemes apply. ISO/IEC 8824:1990(E) clause 28 defines the Object Identifier as 28.9 The semantics of an object identifier value are defined by reference to an object identifier tree. An object identifier tree is a tree whose root corresponds to [the ISO/IEC 8824 standard] and whose vertices [i.e. nodes] correspond to administrative authorities responsible for allocating arcs [i.e. branches] from that vertex. Each arc from that tree is labeled by an object identifier component, which is [an integer number]. Each information object to be identified is allocated precisely one vertex (normally a leaf) and no other information object (of the same or a different type) is allocated to that same vertex. Thus an information object is uniquely and unambiguously identified by the sequence of [integer numbers] (object identifier components) labeling the arcs in a path from the root to the vertex allocated to the information object. 28.10 An object identifier value is semantically an ordered list of object identifier component values. Starting with the root of the object identifier tree, each object identifier component value identifies an arc in the object identifier tree. The last object identifier component value identifies an arc leading to a vertex to which an information object has been assigned. It is this information object, which is identified by the object identifier value. [...] According to ISO/IEC 8824 an object identifier is a sequence of object identifier component values, which are integer numbers. These component values are ordered such that the root of the object identifier tree is the head of the list followed by all the arcs down to the leaf representing the information object identified by the OID. The fact that OID specializes < > represents this path of object identifier component values from the root to the leaf. The leaf and "butLeaf" properties take the opposite view. The leaf is the last object identifier component value in the list, and the "butLeaf" property is all of the OID but the leaf. In a sense, the leaf is the identifier value and all of the OID but the leaf refers to the namespace in which the leaf is unique and meaningful. However, what part of the OID is considered value and what is namespace may be viewed differently. In general, any OID component sequence to the left can be considered the namespace in which the rest of the sequence to the right is defined as a meaningful and unique identifier value. The value-property with a namespace OID as its argument represents this point of view. The value/namespace view on ISO object identifiers has important semantic relevance. It represents the notion of identifier value versus identifier assigning authority (= namespace), which is common in healthcare information systems in general, and HL7 v2.x in particular. section-OID.procedures HL7 shall establish an OID registry and assign OIDs in its branch for HL7 users and vendors upon their request. HL7 shall also assign OIDs to public identifier-assigning authorities both U.S. nationally (e.g., the U.S. State driver license bureaus, U.S. Social Security Administration, HIPAA Provider ID registry, etc.) and internationally (e.g., other countries Social Security Administrations, Citizen ID registries, etc.) The HL7 registered OIDs must be used for these organizations, regardless whether these organizations have other OIDs assigned from other sources. When assigning OIDs to third parties or entities, HL7 shall investigate whether an OID is already assigned for such entities through other sources. It this is the case, HL7 shall record such OID in a catalog, but HL7 shall not assign a duplicate OID in the HL7 branch. If possible, HL7 shall notify a third party when an OID is being assigned for that party in the HL7 branch. Though HL7 shall exercise diligence before assigning an OID in the HL7 branch to third parties, given the lack of a global OID registry mechanism, one cannot make absolutely certain that there is no preexisting OID assignment for such third-party entity. Also, a duplicate assignment can happen in the future through another source. If such cases of supplicate assignment become known to HL7, HL7 shall make efforts to resolve this situation. For continued interoperability in the meantime, the HL7 assigned OID shall be the preferred OID used. While most owners of an OID will "design" their namespace sub-tree in some meaningful way, there is no way to generally infer any meaning on the parts of an OID. HL7 does not standardize or require any namespace sub-structure. An OID owner, or anyone having knowledge about the logical structure of part of an OID, may still use that knowledge to infer information about the associated object; however, the techniques cannot be generalized. Example for a tree of ISO object identifiers. HL7's OID is 2.16.840.1.113883. An HL7 interface must not rely on any knowledge about the substructure of an OID for which it cannot control the assignment policies. protected type ObjectIdentifier alias OID specializes UID, LIST<INT> { INT leaf; OID butLeaf; OID value(OID namespace); literal ST; }; A globally unique string representing an ISO Object Identifier (OID) in a form that consists only of numbers and dots (e.g., "2.16.840.1.113883.3.1"). According to ISO, OIDs are paths in a tree structure, with the left-most number representing the root and the right-most number representing a leaf. Each branch under the root corresponds to an assigning authority. Each of these assigning authorities may, in turn, designate its own set of assigning authorities that work under its auspices, and so on down the line. Eventually, one of these authorities assigns a unique (to it as an assigning authority) number that corresponds to a leaf node on the tree. The leaf may represent an assigning authority (in which case the root OID identifies the authority), or an instance of an object. An assigning authority owns a namespace, consisting of its sub-tree. OIDs are the preferred scheme for unique identifiers. OIDs should always be used except if one of the inclusion criteria for other schemes apply. ISO/IEC 8824:1990(E) clause 28 defines the Object Identifier as 28.9 The semantics of an object identifier value are defined by reference to an object identifier tree. An object identifier tree is a tree whose root corresponds to [the ISO/IEC 8824 standard] and whose vertices [i.e. nodes] correspond to administrative authorities responsible for allocating arcs [i.e. branches] from that vertex. Each arc from that tree is labeled by an object identifier component, which is [an integer number]. Each information object to be identified is allocated precisely one vertex (normally a leaf) and no other information object (of the same or a different type) is allocated to that same vertex. Thus an information object is uniquely and unambiguously identified by the sequence of [integer numbers] (object identifier components) labeling the arcs in a path from the root to the vertex allocated to the information object. 28.10 An object identifier value is semantically an ordered list of object identifier component values. Starting with the root of the object identifier tree, each object identifier component value identifies an arc in the object identifier tree. The last object identifier component value identifies an arc leading to a vertex to which an information object has been assigned. It is this information object, which is identified by the object identifier value. [...] According to ISO/IEC 8824 an object identifier is a sequence of object identifier component values, which are integer numbers. These component values are ordered such that the root of the object identifier tree is the head of the list followed by all the arcs down to the leaf representing the information object identified by the OID. The fact that OID specializes < > represents this path of object identifier component values from the root to the leaf. The leaf and "butLeaf" properties take the opposite view. The leaf is the last object identifier component value in the list, and the "butLeaf" property is all of the OID but the leaf. In a sense, the leaf is the identifier value and all of the OID but the leaf refers to the namespace in which the leaf is unique and meaningful. However, what part of the OID is considered value and what is namespace may be viewed differently. In general, any OID component sequence to the left can be considered the namespace in which the rest of the sequence to the right is defined as a meaningful and unique identifier value. The value-property with a namespace OID as its argument represents this point of view. The value/namespace view on ISO object identifiers has important semantic relevance. It represents the notion of identifier value versus identifier assigning authority (= namespace), which is common in healthcare information systems in general, and HL7 v2.x in particular. section-OID.procedures HL7 shall establish an OID registry and assign OIDs in its branch for HL7 users and vendors upon their request. HL7 shall also assign OIDs to public identifier-assigning authorities both U.S. nationally (e.g., the U.S. State driver license bureaus, U.S. Social Security Administration, HIPAA Provider ID registry, etc.) and internationally (e.g., other countries Social Security Administrations, Citizen ID registries, etc.) The HL7 registered OIDs must be used for these organizations, regardless whether these organizations have other OIDs assigned from other sources. When assigning OIDs to third parties or entities, HL7 shall investigate whether an OID is already assigned for such entities through other sources. It this is the case, HL7 shall record such OID in a catalog, but HL7 shall not assign a duplicate OID in the HL7 branch. If possible, HL7 shall notify a third party when an OID is being assigned for that party in the HL7 branch. Though HL7 shall exercise diligence before assigning an OID in the HL7 branch to third parties, given the lack of a global OID registry mechanism, one cannot make absolutely certain that there is no preexisting OID assignment for such third-party entity. Also, a duplicate assignment can happen in the future through another source. If such cases of supplicate assignment become known to HL7, HL7 shall make efforts to resolve this situation. For continued interoperability in the meantime, the HL7 assigned OID shall be the preferred OID used. While most owners of an OID will "design" their namespace sub-tree in some meaningful way, there is no way to generally infer any meaning on the parts of an OID. HL7 does not standardize or require any namespace sub-structure. An OID owner, or anyone having knowledge about the logical structure of part of an OID, may still use that knowledge to infer information about the associated object; however, the techniques cannot be generalized. Example for a tree of ISO object identifiers. HL7's OID is 2.16.840.1.113883. An HL7 interface must not rely on any knowledge about the substructure of an OID for which it cannot control the assignment policies. protected type ObjectIdentifier alias OID specializes UID, LIST<INT> { INT leaf; OID butLeaf; OID value(OID namespace); literal ST; }; UUID (UniversalUniqueIdentifier) A globally unique string representing a DCE Universal Unique Identifier (UUID) in the common UUID format that consists of 5 hyphen-separated groups of hexadecimal digits having 8, 4, 4, 4, and 12 places respectively. Both the UUID and its string representation are defined by the Open Group, CDE 1.1 Remote Procedure Call specification, Appendix A. UUIDs are assigned based on Ethernet MAC addresses, the point in time of creation and some random component. This mix is believed to generate sufficiently unique identifiers without any organizational policy for identifier assignment (in fact this piggy-backs on the organization of MAC address assignment.) UUIDs are not the preferred identifier scheme for use as HL7 UIDs. UUIDs may be used when identifiers are issued to objects representing individuals (e.g., entity instance identifiers, act event identifiers, etc.) For objects describing classes of things or events (e.g., catalog items), OIDs are the preferred identifier scheme. protected type UniversalUniqueIdentifier alias UUID specializes UID { INT timeLow; INT timeMid; INT timeHighAndVersion; INT clockSequence; INT node; literal ST; }; A globally unique string representing a DCE Universal Unique Identifier (UUID) in the common UUID format that consists of 5 hyphen-separated groups of hexadecimal digits having 8, 4, 4, 4, and 12 places respectively. Both the UUID and its string representation are defined by the Open Group, CDE 1.1 Remote Procedure Call specification, Appendix A. UUIDs are assigned based on Ethernet MAC addresses, the point in time of creation and some random component. This mix is believed to generate sufficiently unique identifiers without any organizational policy for identifier assignment (in fact this piggy-backs on the organization of MAC address assignment.) UUIDs are not the preferred identifier scheme for use as HL7 UIDs. UUIDs may be used when identifiers are issued to objects representing individuals (e.g., entity instance identifiers, act event identifiers, etc.) For objects describing classes of things or events (e.g., catalog items), OIDs are the preferred identifier scheme. protected type UniversalUniqueIdentifier alias UUID specializes UID { INT timeLow; INT timeMid; INT timeHighAndVersion; INT clockSequence; INT node; literal ST; }; A globally unique string representing a DCE Universal Unique Identifier (UUID) in the common UUID format that consists of 5 hyphen-separated groups of hexadecimal digits having 8, 4, 4, 4, and 12 places respectively. Both the UUID and its string representation are defined by the Open Group, CDE 1.1 Remote Procedure Call specification, Appendix A. UUIDs are assigned based on Ethernet MAC addresses, the point in time of creation and some random component. This mix is believed to generate sufficiently unique identifiers without any organizational policy for identifier assignment (in fact this piggy-backs on the organization of MAC address assignment.) UUIDs are not the preferred identifier scheme for use as HL7 UIDs. UUIDs may be used when identifiers are issued to objects representing individuals (e.g., entity instance identifiers, act event identifiers, etc.) For objects describing classes of things or events (e.g., catalog items), OIDs are the preferred identifier scheme. protected type UniversalUniqueIdentifier alias UUID specializes UID { INT timeLow; INT timeMid; INT timeHighAndVersion; INT clockSequence; INT node; literal ST; }; A globally unique string representing a DCE Universal Unique Identifier (UUID) in the common UUID format that consists of 5 hyphen-separated groups of hexadecimal digits having 8, 4, 4, 4, and 12 places respectively. Both the UUID and its string representation are defined by the Open Group, CDE 1.1 Remote Procedure Call specification, Appendix A. UUIDs are assigned based on Ethernet MAC addresses, the point in time of creation and some random component. This mix is believed to generate sufficiently unique identifiers without any organizational policy for identifier assignment (in fact this piggy-backs on the organization of MAC address assignment.) UUIDs are not the preferred identifier scheme for use as HL7 UIDs. UUIDs may be used when identifiers are issued to objects representing individuals (e.g., entity instance identifiers, act event identifiers, etc.) For objects describing classes of things or events (e.g., catalog items), OIDs are the preferred identifier scheme. protected type UniversalUniqueIdentifier alias UUID specializes UID { INT timeLow; INT timeMid; INT timeHighAndVersion; INT clockSequence; INT node; literal ST; }; A globally unique string representing a DCE Universal Unique Identifier (UUID) in the common UUID format that consists of 5 hyphen-separated groups of hexadecimal digits having 8, 4, 4, 4, and 12 places respectively. Both the UUID and its string representation are defined by the Open Group, CDE 1.1 Remote Procedure Call specification, Appendix A. UUIDs are assigned based on Ethernet MAC addresses, the point in time of creation and some random component. This mix is believed to generate sufficiently unique identifiers without any organizational policy for identifier assignment (in fact this piggy-backs on the organization of MAC address assignment.) UUIDs are not the preferred identifier scheme for use as HL7 UIDs. UUIDs may be used when identifiers are issued to objects representing individuals (e.g., entity instance identifiers, act event identifiers, etc.) For objects describing classes of things or events (e.g., catalog items), OIDs are the preferred identifier scheme. protected type UniversalUniqueIdentifier alias UUID specializes UID { INT timeLow; INT timeMid; INT timeHighAndVersion; INT clockSequence; INT node; literal ST; }; A globally unique string representing a DCE Universal Unique Identifier (UUID) in the common UUID format that consists of 5 hyphen-separated groups of hexadecimal digits having 8, 4, 4, 4, and 12 places respectively. Both the UUID and its string representation are defined by the Open Group, CDE 1.1 Remote Procedure Call specification, Appendix A. UUIDs are assigned based on Ethernet MAC addresses, the point in time of creation and some random component. This mix is believed to generate sufficiently unique identifiers without any organizational policy for identifier assignment (in fact this piggy-backs on the organization of MAC address assignment.) UUIDs are not the preferred identifier scheme for use as HL7 UIDs. UUIDs may be used when identifiers are issued to objects representing individuals (e.g., entity instance identifiers, act event identifiers, etc.) For objects describing classes of things or events (e.g., catalog items), OIDs are the preferred identifier scheme. protected type UniversalUniqueIdentifier alias UUID specializes UID { INT timeLow; INT timeMid; INT timeHighAndVersion; INT clockSequence; INT node; literal ST; }; A globally unique string representing a DCE Universal Unique Identifier (UUID) in the common UUID format that consists of 5 hyphen-separated groups of hexadecimal digits having 8, 4, 4, 4, and 12 places respectively. Both the UUID and its string representation are defined by the Open Group, CDE 1.1 Remote Procedure Call specification, Appendix A. UUIDs are assigned based on Ethernet MAC addresses, the point in time of creation and some random component. This mix is believed to generate sufficiently unique identifiers without any organizational policy for identifier assignment (in fact this piggy-backs on the organization of MAC address assignment.) UUIDs are not the preferred identifier scheme for use as HL7 UIDs. UUIDs may be used when identifiers are issued to objects representing individuals (e.g., entity instance identifiers, act event identifiers, etc.) For objects describing classes of things or events (e.g., catalog items), OIDs are the preferred identifier scheme. protected type UniversalUniqueIdentifier alias UUID specializes UID { INT timeLow; INT timeMid; INT timeHighAndVersion; INT clockSequence; INT node; literal ST; }; RUID (HL7ReservedIdentifierScheme) A globally unique string defined exclusively by HL7. Identifiers in this scheme are only defined by balloted HL7 specifications. Local communities or systems must never use such reserved identifiers based on bilateral negotiations. HL7 reserved identifiers are strings that consist only of (US-ASCII) letters, digits and hyphens, where the first character must be a letter. HL7 may assign these reserved identifiers as mnemonic identifiers for major concepts of interest to HL7. protected type HL7ReservedIdentifierScheme alias RUID specializes UID; II (InstanceIdentifier) An identifier that uniquely identifies a thing or object. Examples are object identifier for HL7 RIM objects, medical record number, order id, service catalog item id, Vehicle Identification Number (VIN), etc. Instance identifiers are defined based on ISO object identifiers. type InstanceIdentifier alias II specializes ANY { UID root; ST extension; ST assigningAuthorityName; BL displayable; }; An identifier that uniquely identifies a thing or object. Examples are object identifier for HL7 RIM objects, medical record number, order id, service catalog item id, Vehicle Identification Number (VIN), etc. Instance identifiers are defined based on ISO object identifiers. type InstanceIdentifier alias II specializes ANY { UID root; ST extension; ST assigningAuthorityName; BL displayable; }; An identifier that uniquely identifies a thing or object. Examples are object identifier for HL7 RIM objects, medical record number, order id, service catalog item id, Vehicle Identification Number (VIN), etc. Instance identifiers are defined based on ISO object identifiers. type InstanceIdentifier alias II specializes ANY { UID root; ST extension; ST assigningAuthorityName; BL displayable; }; An identifier that uniquely identifies a thing or object. Examples are object identifier for HL7 RIM objects, medical record number, order id, service catalog item id, Vehicle Identification Number (VIN), etc. Instance identifiers are defined based on ISO object identifiers. type InstanceIdentifier alias II specializes ANY { UID root; ST extension; ST assigningAuthorityName; BL displayable; }; An identifier that uniquely identifies a thing or object. Examples are object identifier for HL7 RIM objects, medical record number, order id, service catalog item id, Vehicle Identification Number (VIN), etc. Instance identifiers are defined based on ISO object identifiers. type InstanceIdentifier alias II specializes ANY { UID root; ST extension; ST assigningAuthorityName; BL displayable; }; An identifier that uniquely identifies a thing or object. Examples are object identifier for HL7 RIM objects, medical record number, order id, service catalog item id, Vehicle Identification Number (VIN), etc. Instance identifiers are defined based on ISO object identifiers. type InstanceIdentifier alias II specializes ANY { UID root; ST extension; ST assigningAuthorityName; BL displayable; }; URL (UniversalResourceLocator) A telecommunications address specified according to Internet standard RFC 2396 []. The URI specifies the protocol and the contact point defined by that protocol for the resource. Notable uses of the telecommunication address data type are for telephone and telefax numbers, e-mail addresses, Hypertext references, FTP references, etc. The Internet standard RFC 2396 [] defines a URI as follows: Just as there are many different methods of access to resources, there are several schemes for describing the location of such resources. The generic syntax for s provides a framework for new schemes to be established using protocols other than those defined in this document. URLs are used to "locate" resources, by providing an abstract identification of the resource location. Having located a resource, a system may perform a variety of operations on the resource, as might be characterized by such words as "access", "update", "replace", "find attributes". In general, only the "access" method needs to be specified for any scheme. protected type UniversalResourceLocator alias URL specializes ANY { CS scheme; ST address; literal ST; }; A telecommunications address specified according to Internet standard RFC 2396 []. The URI specifies the protocol and the contact point defined by that protocol for the resource. Notable uses of the telecommunication address data type are for telephone and telefax numbers, e-mail addresses, Hypertext references, FTP references, etc. The Internet standard RFC 2396 [] defines a URI as follows: Just as there are many different methods of access to resources, there are several schemes for describing the location of such resources. The generic syntax for s provides a framework for new schemes to be established using protocols other than those defined in this document. URLs are used to "locate" resources, by providing an abstract identification of the resource location. Having located a resource, a system may perform a variety of operations on the resource, as might be characterized by such words as "access", "update", "replace", "find attributes". In general, only the "access" method needs to be specified for any scheme. protected type UniversalResourceLocator alias URL specializes ANY { CS scheme; ST address; literal ST; }; A telecommunications address specified according to Internet standard RFC 2396 []. The URI specifies the protocol and the contact point defined by that protocol for the resource. Notable uses of the telecommunication address data type are for telephone and telefax numbers, e-mail addresses, Hypertext references, FTP references, etc. The Internet standard RFC 2396 [] defines a URI as follows: Just as there are many different methods of access to resources, there are several schemes for describing the location of such resources. The generic syntax for s provides a framework for new schemes to be established using protocols other than those defined in this document. URLs are used to "locate" resources, by providing an abstract identification of the resource location. Having located a resource, a system may perform a variety of operations on the resource, as might be characterized by such words as "access", "update", "replace", "find attributes". In general, only the "access" method needs to be specified for any scheme. protected type UniversalResourceLocator alias URL specializes ANY { CS scheme; ST address; literal ST; }; A telecommunications address specified according to Internet standard RFC 2396 []. The URI specifies the protocol and the contact point defined by that protocol for the resource. Notable uses of the telecommunication address data type are for telephone and telefax numbers, e-mail addresses, Hypertext references, FTP references, etc. The Internet standard RFC 2396 [] defines a URI as follows: Just as there are many different methods of access to resources, there are several schemes for describing the location of such resources. The generic syntax for s provides a framework for new schemes to be established using protocols other than those defined in this document. URLs are used to "locate" resources, by providing an abstract identification of the resource location. Having located a resource, a system may perform a variety of operations on the resource, as might be characterized by such words as "access", "update", "replace", "find attributes". In general, only the "access" method needs to be specified for any scheme. protected type UniversalResourceLocator alias URL specializes ANY { CS scheme; ST address; literal ST; }; TEL (TelecommunicationAddress) A telephone number (voice or fax), e-mail address, or other locator for a resource mediated by telecommunication equipment. The address is specified as a Universal Resource Locator (URL) qualified by time specification and use codes that help in deciding which address to use for a given time and purpose. The semantics of a telecommunication address is that a communicating entity (the responder) listens and responds to that address, and therefore can be contacted by an other communicating entity (the initiator.) The responder of a telecommunication address may be an automatic service that can respond with information (e.g., FTP or HTTP services.) In such case a telecommunication address is a reference to that information accessible through that address. A telecommunication address value can thus be resolved to some information (in the form of encapsulated data, .) The telecommunication address is an extension of the Universal Resource Locator ( ) specified according to Internet standard RFC 2396 []. The specifies the protocol and the contact point defined by that protocol for the resource. Notable use cases for the telecommunication address data type are for telephone and fax numbers, e-mail addresses, Hypertext references, FTP references, etc. type TelecommunicationAddress alias TEL specializes URL { GTS useablePeriod; SET<CS> use; }; A telephone number (voice or fax), e-mail address, or other locator for a resource mediated by telecommunication equipment. The address is specified as a Universal Resource Locator (URL) qualified by time specification and use codes that help in deciding which address to use for a given time and purpose. The semantics of a telecommunication address is that a communicating entity (the responder) listens and responds to that address, and therefore can be contacted by an other communicating entity (the initiator.) The responder of a telecommunication address may be an automatic service that can respond with information (e.g., FTP or HTTP services.) In such case a telecommunication address is a reference to that information accessible through that address. A telecommunication address value can thus be resolved to some information (in the form of encapsulated data, .) The telecommunication address is an extension of the Universal Resource Locator ( ) specified according to Internet standard RFC 2396 []. The specifies the protocol and the contact point defined by that protocol for the resource. Notable use cases for the telecommunication address data type are for telephone and fax numbers, e-mail addresses, Hypertext references, FTP references, etc. type TelecommunicationAddress alias TEL specializes URL { GTS useablePeriod; SET<CS> use; }; A telephone number (voice or fax), e-mail address, or other locator for a resource mediated by telecommunication equipment. The address is specified as a Universal Resource Locator (URL) qualified by time specification and use codes that help in deciding which address to use for a given time and purpose. The semantics of a telecommunication address is that a communicating entity (the responder) listens and responds to that address, and therefore can be contacted by an other communicating entity (the initiator.) The responder of a telecommunication address may be an automatic service that can respond with information (e.g., FTP or HTTP services.) In such case a telecommunication address is a reference to that information accessible through that address. A telecommunication address value can thus be resolved to some information (in the form of encapsulated data, .) The telecommunication address is an extension of the Universal Resource Locator ( ) specified according to Internet standard RFC 2396 []. The specifies the protocol and the contact point defined by that protocol for the resource. Notable use cases for the telecommunication address data type are for telephone and fax numbers, e-mail addresses, Hypertext references, FTP references, etc. type TelecommunicationAddress alias TEL specializes URL { GTS useablePeriod; SET<CS> use; }; A telephone number (voice or fax), e-mail address, or other locator for a resource mediated by telecommunication equipment. The address is specified as a Universal Resource Locator (URL) qualified by time specification and use codes that help in deciding which address to use for a given time and purpose. The semantics of a telecommunication address is that a communicating entity (the responder) listens and responds to that address, and therefore can be contacted by an other communicating entity (the initiator.) The responder of a telecommunication address may be an automatic service that can respond with information (e.g., FTP or HTTP services.) In such case a telecommunication address is a reference to that information accessible through that address. A telecommunication address value can thus be resolved to some information (in the form of encapsulated data, .) The telecommunication address is an extension of the Universal Resource Locator ( ) specified according to Internet standard RFC 2396 []. The specifies the protocol and the contact point defined by that protocol for the resource. Notable use cases for the telecommunication address data type are for telephone and fax numbers, e-mail addresses, Hypertext references, FTP references, etc. type TelecommunicationAddress alias TEL specializes URL { GTS useablePeriod; SET<CS> use; }; ADXP (AddressPart) A character string that may have a type-tag signifying its role in the address. Typical parts that exist in about every address are street, house number, or post box, postal code, city, country but other roles may be defined regionally, nationally, or on an enterprise level (e.g. in military addresses). Addresses are usually broken up into lines, which are indicated by special line-breaking delimiter elements (e.g., DEL). protected type AddressPart alias ADXP specializes ST { CS partType; }; A character string that may have a type-tag signifying its role in the address. Typical parts that exist in about every address are street, house number, or post box, postal code, city, country but other roles may be defined regionally, nationally, or on an enterprise level (e.g. in military addresses). Addresses are usually broken up into lines, which are indicated by special line-breaking delimiter elements (e.g., DEL). protected type AddressPart alias ADXP specializes ST { CS partType; }; AD (PostalAddress) Mailing and home or office addresses. A sequence of address parts, such as street or post office Box, city, postal code, country, etc. The is primarily used to communicate data that will allow printing mail labels, that will allow a person to physically visit that address. The postal address data type is not supposed to be a container for additional information that might be useful for finding geographic locations (e.g., GPS coordinates) or for performing epidemiological studies. Such additional information is captured by other, more appropriate HL7 elements. Addresses are conceptualized as text with added logical mark-up. The mark-up may break the address into lines and may describe in detail the role of each address part if it is known. Address parts occur in the address in the order in which they would be printed on a mailing label. The approach is similar to HTML or XML markup of text (but it is not technically limited to XML representations.) Addresses are essentially sequences of address parts, but add a "use" code and a valid time range for information about if and when the address can be used for a given purpose. type PostalAddress alias AD specializes LIST<ADXP> { SET<CS> use; GTS useablePeriod; BL isNotOrdered; ST formatted; }; Mailing and home or office addresses. A sequence of address parts, such as street or post office Box, city, postal code, country, etc. The is primarily used to communicate data that will allow printing mail labels, that will allow a person to physically visit that address. The postal address data type is not supposed to be a container for additional information that might be useful for finding geographic locations (e.g., GPS coordinates) or for performing epidemiological studies. Such additional information is captured by other, more appropriate HL7 elements. Addresses are conceptualized as text with added logical mark-up. The mark-up may break the address into lines and may describe in detail the role of each address part if it is known. Address parts occur in the address in the order in which they would be printed on a mailing label. The approach is similar to HTML or XML markup of text (but it is not technically limited to XML representations.) Addresses are essentially sequences of address parts, but add a "use" code and a valid time range for information about if and when the address can be used for a given purpose. type PostalAddress alias AD specializes LIST<ADXP> { SET<CS> use; GTS useablePeriod; BL isNotOrdered; ST formatted; }; Mailing and home or office addresses. A sequence of address parts, such as street or post office Box, city, postal code, country, etc. The is primarily used to communicate data that will allow printing mail labels, that will allow a person to physically visit that address. The postal address data type is not supposed to be a container for additional information that might be useful for finding geographic locations (e.g., GPS coordinates) or for performing epidemiological studies. Such additional information is captured by other, more appropriate HL7 elements. Addresses are conceptualized as text with added logical mark-up. The mark-up may break the address into lines and may describe in detail the role of each address part if it is known. Address parts occur in the address in the order in which they would be printed on a mailing label. The approach is similar to HTML or XML markup of text (but it is not technically limited to XML representations.) Addresses are essentially sequences of address parts, but add a "use" code and a valid time range for information about if and when the address can be used for a given purpose. type PostalAddress alias AD specializes LIST<ADXP> { SET<CS> use; GTS useablePeriod; BL isNotOrdered; ST formatted; }; Mailing and home or office addresses. A sequence of address parts, such as street or post office Box, city, postal code, country, etc. The is primarily used to communicate data that will allow printing mail labels, that will allow a person to physically visit that address. The postal address data type is not supposed to be a container for additional information that might be useful for finding geographic locations (e.g., GPS coordinates) or for performing epidemiological studies. Such additional information is captured by other, more appropriate HL7 elements. Addresses are conceptualized as text with added logical mark-up. The mark-up may break the address into lines and may describe in detail the role of each address part if it is known. Address parts occur in the address in the order in which they would be printed on a mailing label. The approach is similar to HTML or XML markup of text (but it is not technically limited to XML representations.) Addresses are essentially sequences of address parts, but add a "use" code and a valid time range for information about if and when the address can be used for a given purpose. type PostalAddress alias AD specializes LIST<ADXP> { SET<CS> use; GTS useablePeriod; BL isNotOrdered; ST formatted; }; Mailing and home or office addresses. A sequence of address parts, such as street or post office Box, city, postal code, country, etc. The is primarily used to communicate data that will allow printing mail labels, that will allow a person to physically visit that address. The postal address data type is not supposed to be a container for additional information that might be useful for finding geographic locations (e.g., GPS coordinates) or for performing epidemiological studies. Such additional information is captured by other, more appropriate HL7 elements. Addresses are conceptualized as text with added logical mark-up. The mark-up may break the address into lines and may describe in detail the role of each address part if it is known. Address parts occur in the address in the order in which they would be printed on a mailing label. The approach is similar to HTML or XML markup of text (but it is not technically limited to XML representations.) Addresses are essentially sequences of address parts, but add a "use" code and a valid time range for information about if and when the address can be used for a given purpose. type PostalAddress alias AD specializes LIST<ADXP> { SET<CS> use; GTS useablePeriod; BL isNotOrdered; ST formatted; }; Mailing and home or office addresses. A sequence of address parts, such as street or post office Box, city, postal code, country, etc. The is primarily used to communicate data that will allow printing mail labels, that will allow a person to physically visit that address. The postal address data type is not supposed to be a container for additional information that might be useful for finding geographic locations (e.g., GPS coordinates) or for performing epidemiological studies. Such additional information is captured by other, more appropriate HL7 elements. Addresses are conceptualized as text with added logical mark-up. The mark-up may break the address into lines and may describe in detail the role of each address part if it is known. Address parts occur in the address in the order in which they would be printed on a mailing label. The approach is similar to HTML or XML markup of text (but it is not technically limited to XML representations.) Addresses are essentially sequences of address parts, but add a "use" code and a valid time range for information about if and when the address can be used for a given purpose. type PostalAddress alias AD specializes LIST<ADXP> { SET<CS> use; GTS useablePeriod; BL isNotOrdered; ST formatted; }; ENXP (EntityNamePart) A character string token representing a part of a name. May have a type code signifying the role of the part in the whole entity name, and a qualifier code for more detail about the name part type. Typical name parts for person names are given names, and family names, titles, etc. protected type EntityNamePart alias ENXP specializes ST { CS partType; SET<CS> qualifier; }; A character string token representing a part of a name. May have a type code signifying the role of the part in the whole entity name, and a qualifier code for more detail about the name part type. Typical name parts for person names are given names, and family names, titles, etc. protected type EntityNamePart alias ENXP specializes ST { CS partType; SET<CS> qualifier; }; A character string token representing a part of a name. May have a type code signifying the role of the part in the whole entity name, and a qualifier code for more detail about the name part type. Typical name parts for person names are given names, and family names, titles, etc. protected type EntityNamePart alias ENXP specializes ST { CS partType; SET<CS> qualifier; }; EN (EntityName) A name for a person, organization, place or thing. A sequence of name parts, such as given name or family name, prefix, suffix, etc. Examples for entity name values are "Jim Bob Walton, Jr.", "Health Level Seven, Inc.", "Lake Tahoe", etc. An entity name may be as simple as a character string or may consist of several entity name parts, such as, "Jim", "Bob", "Walton", and "Jr.", "Health Level Seven" and "Inc.", "Lake" and "Tahoe". Entity names are conceptualized as text with added logical mark-up. Name parts occur in a natural order in which they would be displayed, as opposed to in a order detemined by name part. The ordeing of the name parts is significant a feature that replaces the need for a separate "display name" property. Applications may change that ordering of name parts to account for their user's customary ordering of name parts. The approach is similar to HTML or XML markup of text (but it is not technically limited to XML representations.) Entity names are essentially sequences of entity name parts, but add a "use" code and a valid time range for information about when the name was used and how to choose between multiple aliases that may be valid at the same point in time. Three restrictions to Entity Name are defined in order to allow making specific constraints for certain kinds of entities, trivial name ( ), person name ( ), and organization name ( ). A very simple encoding of "Adam A. Everyman" would be: Adam A. Everyman None of the special qualifiers need to be mentioned if they are unknown or irrelevant. The next example shows extensive use of multiple given names, prefixes, suffixes, for academic degrees, nobility titles, vorvoegsels ("van"), and professional designations. Dr. phil. Regina Johanna Maria Graefin Hochheim-Weilenfels NCFSA The next example is an organization name, "Health Level Seven, Inc." in simple string form: Health Level Seven, Inc. and as a fully parsed name Health Level Seven, Inc. The following example shows a Japanese name in the three forms: ideographic (Kanji), syllabic (Hiragana), and alphabetic (Romaji). ?? ?? ??? ??? KIMURA MICHIO type EntityName alias EN specializes LIST<ENXP> { SET<CS> use; IVL<TS> validTime; ST formatted; }; A name for a person, organization, place or thing. A sequence of name parts, such as given name or family name, prefix, suffix, etc. Examples for entity name values are "Jim Bob Walton, Jr.", "Health Level Seven, Inc.", "Lake Tahoe", etc. An entity name may be as simple as a character string or may consist of several entity name parts, such as, "Jim", "Bob", "Walton", and "Jr.", "Health Level Seven" and "Inc.", "Lake" and "Tahoe". Entity names are conceptualized as text with added logical mark-up. Name parts occur in a natural order in which they would be displayed, as opposed to in a order detemined by name part. The ordeing of the name parts is significant a feature that replaces the need for a separate "display name" property. Applications may change that ordering of name parts to account for their user's customary ordering of name parts. The approach is similar to HTML or XML markup of text (but it is not technically limited to XML representations.) Entity names are essentially sequences of entity name parts, but add a "use" code and a valid time range for information about when the name was used and how to choose between multiple aliases that may be valid at the same point in time. Three restrictions to Entity Name are defined in order to allow making specific constraints for certain kinds of entities, trivial name ( ), person name ( ), and organization name ( ). A very simple encoding of "Adam A. Everyman" would be: Adam A. Everyman None of the special qualifiers need to be mentioned if they are unknown or irrelevant. The next example shows extensive use of multiple given names, prefixes, suffixes, for academic degrees, nobility titles, vorvoegsels ("van"), and professional designations. Dr. phil. Regina Johanna Maria Graefin Hochheim-Weilenfels NCFSA The next example is an organization name, "Health Level Seven, Inc." in simple string form: Health Level Seven, Inc. and as a fully parsed name Health Level Seven, Inc. The following example shows a Japanese name in the three forms: ideographic (Kanji), syllabic (Hiragana), and alphabetic (Romaji). ?? ?? ??? ??? KIMURA MICHIO type EntityName alias EN specializes LIST<ENXP> { SET<CS> use; IVL<TS> validTime; ST formatted; }; A name for a person, organization, place or thing. A sequence of name parts, such as given name or family name, prefix, suffix, etc. Examples for entity name values are "Jim Bob Walton, Jr.", "Health Level Seven, Inc.", "Lake Tahoe", etc. An entity name may be as simple as a character string or may consist of several entity name parts, such as, "Jim", "Bob", "Walton", and "Jr.", "Health Level Seven" and "Inc.", "Lake" and "Tahoe". Entity names are conceptualized as text with added logical mark-up. Name parts occur in a natural order in which they would be displayed, as opposed to in a order detemined by name part. The ordeing of the name parts is significant a feature that replaces the need for a separate "display name" property. Applications may change that ordering of name parts to account for their user's customary ordering of name parts. The approach is similar to HTML or XML markup of text (but it is not technically limited to XML representations.) Entity names are essentially sequences of entity name parts, but add a "use" code and a valid time range for information about when the name was used and how to choose between multiple aliases that may be valid at the same point in time. Three restrictions to Entity Name are defined in order to allow making specific constraints for certain kinds of entities, trivial name ( ), person name ( ), and organization name ( ). A very simple encoding of "Adam A. Everyman" would be: Adam A. Everyman None of the special qualifiers need to be mentioned if they are unknown or irrelevant. The next example shows extensive use of multiple given names, prefixes, suffixes, for academic degrees, nobility titles, vorvoegsels ("van"), and professional designations. Dr. phil. Regina Johanna Maria Graefin Hochheim-Weilenfels NCFSA The next example is an organization name, "Health Level Seven, Inc." in simple string form: Health Level Seven, Inc. and as a fully parsed name Health Level Seven, Inc. The following example shows a Japanese name in the three forms: ideographic (Kanji), syllabic (Hiragana), and alphabetic (Romaji). ?? ?? ??? ??? KIMURA MICHIO type EntityName alias EN specializes LIST<ENXP> { SET<CS> use; IVL<TS> validTime; ST formatted; }; A name for a person, organization, place or thing. A sequence of name parts, such as given name or family name, prefix, suffix, etc. Examples for entity name values are "Jim Bob Walton, Jr.", "Health Level Seven, Inc.", "Lake Tahoe", etc. An entity name may be as simple as a character string or may consist of several entity name parts, such as, "Jim", "Bob", "Walton", and "Jr.", "Health Level Seven" and "Inc.", "Lake" and "Tahoe". Entity names are conceptualized as text with added logical mark-up. Name parts occur in a natural order in which they would be displayed, as opposed to in a order detemined by name part. The ordeing of the name parts is significant a feature that replaces the need for a separate "display name" property. Applications may change that ordering of name parts to account for their user's customary ordering of name parts. The approach is similar to HTML or XML markup of text (but it is not technically limited to XML representations.) Entity names are essentially sequences of entity name parts, but add a "use" code and a valid time range for information about when the name was used and how to choose between multiple aliases that may be valid at the same point in time. Three restrictions to Entity Name are defined in order to allow making specific constraints for certain kinds of entities, trivial name ( ), person name ( ), and organization name ( ). A very simple encoding of "Adam A. Everyman" would be: Adam A. Everyman None of the special qualifiers need to be mentioned if they are unknown or irrelevant. The next example shows extensive use of multiple given names, prefixes, suffixes, for academic degrees, nobility titles, vorvoegsels ("van"), and professional designations. Dr. phil. Regina Johanna Maria Graefin Hochheim-Weilenfels NCFSA The next example is an organization name, "Health Level Seven, Inc." in simple string form: Health Level Seven, Inc. and as a fully parsed name Health Level Seven, Inc. The following example shows a Japanese name in the three forms: ideographic (Kanji), syllabic (Hiragana), and alphabetic (Romaji). ?? ?? ??? ??? KIMURA MICHIO type EntityName alias EN specializes LIST<ENXP> { SET<CS> use; IVL<TS> validTime; ST formatted; }; A name for a person, organization, place or thing. A sequence of name parts, such as given name or family name, prefix, suffix, etc. Examples for entity name values are "Jim Bob Walton, Jr.", "Health Level Seven, Inc.", "Lake Tahoe", etc. An entity name may be as simple as a character string or may consist of several entity name parts, such as, "Jim", "Bob", "Walton", and "Jr.", "Health Level Seven" and "Inc.", "Lake" and "Tahoe". Entity names are conceptualized as text with added logical mark-up. Name parts occur in a natural order in which they would be displayed, as opposed to in a order detemined by name part. The ordeing of the name parts is significant a feature that replaces the need for a separate "display name" property. Applications may change that ordering of name parts to account for their user's customary ordering of name parts. The approach is similar to HTML or XML markup of text (but it is not technically limited to XML representations.) Entity names are essentially sequences of entity name parts, but add a "use" code and a valid time range for information about when the name was used and how to choose between multiple aliases that may be valid at the same point in time. Three restrictions to Entity Name are defined in order to allow making specific constraints for certain kinds of entities, trivial name ( ), person name ( ), and organization name ( ). A very simple encoding of "Adam A. Everyman" would be: Adam A. Everyman None of the special qualifiers need to be mentioned if they are unknown or irrelevant. The next example shows extensive use of multiple given names, prefixes, suffixes, for academic degrees, nobility titles, vorvoegsels ("van"), and professional designations. Dr. phil. Regina Johanna Maria Graefin Hochheim-Weilenfels NCFSA The next example is an organization name, "Health Level Seven, Inc." in simple string form: Health Level Seven, Inc. and as a fully parsed name Health Level Seven, Inc. The following example shows a Japanese name in the three forms: ideographic (Kanji), syllabic (Hiragana), and alphabetic (Romaji). ?? ?? ??? ??? KIMURA MICHIO type EntityName alias EN specializes LIST<ENXP> { SET<CS> use; IVL<TS> validTime; ST formatted; }; TN (TrivialName) A restriction of entity name that is effectively a simple string used for a simple name for things and places. The is a that consists of only one name part without any name part type or qualifier. The , and its single name part are therefore equivalent to a simple character string. This equivalence is expressed by a defined demotion to and promotion from . Trivial names are typically used for places and things, such as Lake Erie or Reagan National Airport: type TrivialName alias TN specializes EN { demotion ST; promotion TN (ST x); }; A restriction of entity name that is effectively a simple string used for a simple name for things and places. The is a that consists of only one name part without any name part type or qualifier. The , and its single name part are therefore equivalent to a simple character string. This equivalence is expressed by a defined demotion to and promotion from . Trivial names are typically used for places and things, such as Lake Erie or Reagan National Airport: type TrivialName alias TN specializes EN { demotion ST; promotion TN (ST x); }; A restriction of entity name that is effectively a simple string used for a simple name for things and places. The is a that consists of only one name part without any name part type or qualifier. The , and its single name part are therefore equivalent to a simple character string. This equivalence is expressed by a defined demotion to and promotion from . Trivial names are typically used for places and things, such as Lake Erie or Reagan National Airport: type TrivialName alias TN specializes EN { demotion ST; promotion TN (ST x); }; PN (PersonName) An used when the named Entity is a Person. A sequence of name parts, such as given name or family name, prefix, suffix, etc. A name part is a restriction of entity name part that only allows those entity name parts qualifiers applicable to person names. Since the structure of entity name is mostly determined by the requirements of person name, the restriction is very minor. Since most of the functionality of entity name is in support of person names, the person name ( ) is only a very minor restriction on the entity name part qualifier. type PersonName alias PN specializes EN; ON (OrganizationName) An used when the named Entity is an Organization. A sequence of name parts. A name for an organization, such as "Health Level Seven, Inc." An organization name consists only of untyped name parts, prefixes, suffixes, and delimiters. The following is the organization name, "Health Level Seven, Inc." in a simple string form: Health Level Seven, Inc.; And with the legal status "Inc." as a distinguished name part: Health Level Seven, Inc. type OrganizationName alias ON specializes EN; QTY (Quantity) The quantity data type is an abstract generalization for all data types (1) whose value set has an order relation (less-or-equal) and (2) where difference is defined in all of the data type's totally ordered value subsets. The quantity type abstraction is needed in defining certain other types, such as the interval and the probability distribution. abstract type Quantity alias QTY specializes ANY { BL lessOrEqual(QTY x); BL compares(QTY x); TYPE diffType; QTY minus(QTY x); QTY plus(QTY x); BL isZero; BL lessThan(QTY x); BL greaterOrEqual(QTY x); BL greaterThan(QTY x); }; The quantity data type is an abstract generalization for all data types (1) whose value set has an order relation (less-or-equal) and (2) where difference is defined in all of the data type's totally ordered value subsets. The quantity type abstraction is needed in defining certain other types, such as the interval and the probability distribution. abstract type Quantity alias QTY specializes ANY { BL lessOrEqual(QTY x); BL compares(QTY x); TYPE diffType; QTY minus(QTY x); QTY plus(QTY x); BL isZero; BL lessThan(QTY x); BL greaterOrEqual(QTY x); BL greaterThan(QTY x); }; The quantity data type is an abstract generalization for all data types (1) whose value set has an order relation (less-or-equal) and (2) where difference is defined in all of the data type's totally ordered value subsets. The quantity type abstraction is needed in defining certain other types, such as the interval and the probability distribution. abstract type Quantity alias QTY specializes ANY { BL lessOrEqual(QTY x); BL compares(QTY x); TYPE diffType; QTY minus(QTY x); QTY plus(QTY x); BL isZero; BL lessThan(QTY x); BL greaterOrEqual(QTY x); BL greaterThan(QTY x); }; The quantity data type is an abstract generalization for all data types (1) whose value set has an order relation (less-or-equal) and (2) where difference is defined in all of the data type's totally ordered value subsets. The quantity type abstraction is needed in defining certain other types, such as the interval and the probability distribution. abstract type Quantity alias QTY specializes ANY { BL lessOrEqual(QTY x); BL compares(QTY x); TYPE diffType; QTY minus(QTY x); QTY plus(QTY x); BL isZero; BL lessThan(QTY x); BL greaterOrEqual(QTY x); BL greaterThan(QTY x); }; The quantity data type is an abstract generalization for all data types (1) whose value set has an order relation (less-or-equal) and (2) where difference is defined in all of the data type's totally ordered value subsets. The quantity type abstraction is needed in defining certain other types, such as the interval and the probability distribution. abstract type Quantity alias QTY specializes ANY { BL lessOrEqual(QTY x); BL compares(QTY x); TYPE diffType; QTY minus(QTY x); QTY plus(QTY x); BL isZero; BL lessThan(QTY x); BL greaterOrEqual(QTY x); BL greaterThan(QTY x); }; The quantity data type is an abstract generalization for all data types (1) whose value set has an order relation (less-or-equal) and (2) where difference is defined in all of the data type's totally ordered value subsets. The quantity type abstraction is needed in defining certain other types, such as the interval and the probability distribution. abstract type Quantity alias QTY specializes ANY { BL lessOrEqual(QTY x); BL compares(QTY x); TYPE diffType; QTY minus(QTY x); QTY plus(QTY x); BL isZero; BL lessThan(QTY x); BL greaterOrEqual(QTY x); BL greaterThan(QTY x); }; The quantity data type is an abstract generalization for all data types (1) whose value set has an order relation (less-or-equal) and (2) where difference is defined in all of the data type's totally ordered value subsets. The quantity type abstraction is needed in defining certain other types, such as the interval and the probability distribution. abstract type Quantity alias QTY specializes ANY { BL lessOrEqual(QTY x); BL compares(QTY x); TYPE diffType; QTY minus(QTY x); QTY plus(QTY x); BL isZero; BL lessThan(QTY x); BL greaterOrEqual(QTY x); BL greaterThan(QTY x); }; The quantity data type is an abstract generalization for all data types (1) whose value set has an order relation (less-or-equal) and (2) where difference is defined in all of the data type's totally ordered value subsets. The quantity type abstraction is needed in defining certain other types, such as the interval and the probability distribution. abstract type Quantity alias QTY specializes ANY { BL lessOrEqual(QTY x); BL compares(QTY x); TYPE diffType; QTY minus(QTY x); QTY plus(QTY x); BL isZero; BL lessThan(QTY x); BL greaterOrEqual(QTY x); BL greaterThan(QTY x); }; The quantity data type is an abstract generalization for all data types (1) whose value set has an order relation (less-or-equal) and (2) where difference is defined in all of the data type's totally ordered value subsets. The quantity type abstraction is needed in defining certain other types, such as the interval and the probability distribution. abstract type Quantity alias QTY specializes ANY { BL lessOrEqual(QTY x); BL compares(QTY x); TYPE diffType; QTY minus(QTY x); QTY plus(QTY x); BL isZero; BL lessThan(QTY x); BL greaterOrEqual(QTY x); BL greaterThan(QTY x); }; The quantity data type is an abstract generalization for all data types (1) whose value set has an order relation (less-or-equal) and (2) where difference is defined in all of the data type's totally ordered value subsets. The quantity type abstraction is needed in defining certain other types, such as the interval and the probability distribution. abstract type Quantity alias QTY specializes ANY { BL lessOrEqual(QTY x); BL compares(QTY x); TYPE diffType; QTY minus(QTY x); QTY plus(QTY x); BL isZero; BL lessThan(QTY x); BL greaterOrEqual(QTY x); BL greaterThan(QTY x); }; The quantity data type is an abstract generalization for all data types (1) whose value set has an order relation (less-or-equal) and (2) where difference is defined in all of the data type's totally ordered value subsets. The quantity type abstraction is needed in defining certain other types, such as the interval and the probability distribution. abstract type Quantity alias QTY specializes ANY { BL lessOrEqual(QTY x); BL compares(QTY x); TYPE diffType; QTY minus(QTY x); QTY plus(QTY x); BL isZero; BL lessThan(QTY x); BL greaterOrEqual(QTY x); BL greaterThan(QTY x); }; INT (IntegerNumber) Integer numbers (-1,0,1,2, 100, 3398129, etc.) are precise numbers that are results of counting and enumerating. Integer numbers are discrete, the set of integers is infinite but countable. No arbitrary limit is imposed on the range of integer numbers. Two NULL flavors are defined for the positive and negative infinity. Since the integer number data type includes all of the semantics of the mathematical integer number concept, the basic operations plus (addition) and times (multiplication) are defined. These operations are defined here as characterizing operations in the sense of ISO 11404, and because these operations are needed in other parts of this specification, namely the semantics of the literal form. The traditional recursive definitions of addition and multiplication are due to Grassmann, and use the notion of . H. Grassman. Lehrbuch der Arithmetik. 1861. We prefer Grassman's original axioms to the Peano axioms, because Grassman's axioms work for all integers, not just for natural numbers. Also, "it is rather well-known, through Peano's own acknowledgment, that Peano borrowed his axioms from Dedekind and made extensive use of Grassmann's work in his development of the axioms." (Hao Wang. The Axiomatization of Arithmetic. J. Symb. Logic; 1957:22(2); p. 145.) type IntegerNumber alias INT specializes QTY { INT successor; INT plus(QTY x); INT times(INT x); INT predecessor; INT negated; BL nonNegative; BL isNegative; INT dividedBy(INT x); INT remainder(INT x); BL isOne; literal ST; }; Integer numbers (-1,0,1,2, 100, 3398129, etc.) are precise numbers that are results of counting and enumerating. Integer numbers are discrete, the set of integers is infinite but countable. No arbitrary limit is imposed on the range of integer numbers. Two NULL flavors are defined for the positive and negative infinity. Since the integer number data type includes all of the semantics of the mathematical integer number concept, the basic operations plus (addition) and times (multiplication) are defined. These operations are defined here as characterizing operations in the sense of ISO 11404, and because these operations are needed in other parts of this specification, namely the semantics of the literal form. The traditional recursive definitions of addition and multiplication are due to Grassmann, and use the notion of . H. Grassman. Lehrbuch der Arithmetik. 1861. We prefer Grassman's original axioms to the Peano axioms, because Grassman's axioms work for all integers, not just for natural numbers. Also, "it is rather well-known, through Peano's own acknowledgment, that Peano borrowed his axioms from Dedekind and made extensive use of Grassmann's work in his development of the axioms." (Hao Wang. The Axiomatization of Arithmetic. J. Symb. Logic; 1957:22(2); p. 145.) type IntegerNumber alias INT specializes QTY { INT successor; INT plus(QTY x); INT times(INT x); INT predecessor; INT negated; BL nonNegative; BL isNegative; INT dividedBy(INT x); INT remainder(INT x); BL isOne; literal ST; }; Integer numbers (-1,0,1,2, 100, 3398129, etc.) are precise numbers that are results of counting and enumerating. Integer numbers are discrete, the set of integers is infinite but countable. No arbitrary limit is imposed on the range of integer numbers. Two NULL flavors are defined for the positive and negative infinity. Since the integer number data type includes all of the semantics of the mathematical integer number concept, the basic operations plus (addition) and times (multiplication) are defined. These operations are defined here as characterizing operations in the sense of ISO 11404, and because these operations are needed in other parts of this specification, namely the semantics of the literal form. The traditional recursive definitions of addition and multiplication are due to Grassmann, and use the notion of . H. Grassman. Lehrbuch der Arithmetik. 1861. We prefer Grassman's original axioms to the Peano axioms, because Grassman's axioms work for all integers, not just for natural numbers. Also, "it is rather well-known, through Peano's own acknowledgment, that Peano borrowed his axioms from Dedekind and made extensive use of Grassmann's work in his development of the axioms." (Hao Wang. The Axiomatization of Arithmetic. J. Symb. Logic; 1957:22(2); p. 145.) type IntegerNumber alias INT specializes QTY { INT successor; INT plus(QTY x); INT times(INT x); INT predecessor; INT negated; BL nonNegative; BL isNegative; INT dividedBy(INT x); INT remainder(INT x); BL isOne; literal ST; }; Integer numbers (-1,0,1,2, 100, 3398129, etc.) are precise numbers that are results of counting and enumerating. Integer numbers are discrete, the set of integers is infinite but countable. No arbitrary limit is imposed on the range of integer numbers. Two NULL flavors are defined for the positive and negative infinity. Since the integer number data type includes all of the semantics of the mathematical integer number concept, the basic operations plus (addition) and times (multiplication) are defined. These operations are defined here as characterizing operations in the sense of ISO 11404, and because these operations are needed in other parts of this specification, namely the semantics of the literal form. The traditional recursive definitions of addition and multiplication are due to Grassmann, and use the notion of . H. Grassman. Lehrbuch der Arithmetik. 1861. We prefer Grassman's original axioms to the Peano axioms, because Grassman's axioms work for all integers, not just for natural numbers. Also, "it is rather well-known, through Peano's own acknowledgment, that Peano borrowed his axioms from Dedekind and made extensive use of Grassmann's work in his development of the axioms." (Hao Wang. The Axiomatization of Arithmetic. J. Symb. Logic; 1957:22(2); p. 145.) type IntegerNumber alias INT specializes QTY { INT successor; INT plus(QTY x); INT times(INT x); INT predecessor; INT negated; BL nonNegative; BL isNegative; INT dividedBy(INT x); INT remainder(INT x); BL isOne; literal ST; }; Integer numbers (-1,0,1,2, 100, 3398129, etc.) are precise numbers that are results of counting and enumerating. Integer numbers are discrete, the set of integers is infinite but countable. No arbitrary limit is imposed on the range of integer numbers. Two NULL flavors are defined for the positive and negative infinity. Since the integer number data type includes all of the semantics of the mathematical integer number concept, the basic operations plus (addition) and times (multiplication) are defined. These operations are defined here as characterizing operations in the sense of ISO 11404, and because these operations are needed in other parts of this specification, namely the semantics of the literal form. The traditional recursive definitions of addition and multiplication are due to Grassmann, and use the notion of . H. Grassman. Lehrbuch der Arithmetik. 1861. We prefer Grassman's original axioms to the Peano axioms, because Grassman's axioms work for all integers, not just for natural numbers. Also, "it is rather well-known, through Peano's own acknowledgment, that Peano borrowed his axioms from Dedekind and made extensive use of Grassmann's work in his development of the axioms." (Hao Wang. The Axiomatization of Arithmetic. J. Symb. Logic; 1957:22(2); p. 145.) type IntegerNumber alias INT specializes QTY { INT successor; INT plus(QTY x); INT times(INT x); INT predecessor; INT negated; BL nonNegative; BL isNegative; INT dividedBy(INT x); INT remainder(INT x); BL isOne; literal ST; }; Integer numbers (-1,0,1,2, 100, 3398129, etc.) are precise numbers that are results of counting and enumerating. Integer numbers are discrete, the set of integers is infinite but countable. No arbitrary limit is imposed on the range of integer numbers. Two NULL flavors are defined for the positive and negative infinity. Since the integer number data type includes all of the semantics of the mathematical integer number concept, the basic operations plus (addition) and times (multiplication) are defined. These operations are defined here as characterizing operations in the sense of ISO 11404, and because these operations are needed in other parts of this specification, namely the semantics of the literal form. The traditional recursive definitions of addition and multiplication are due to Grassmann, and use the notion of . H. Grassman. Lehrbuch der Arithmetik. 1861. We prefer Grassman's original axioms to the Peano axioms, because Grassman's axioms work for all integers, not just for natural numbers. Also, "it is rather well-known, through Peano's own acknowledgment, that Peano borrowed his axioms from Dedekind and made extensive use of Grassmann's work in his development of the axioms." (Hao Wang. The Axiomatization of Arithmetic. J. Symb. Logic; 1957:22(2); p. 145.) type IntegerNumber alias INT specializes QTY { INT successor; INT plus(QTY x); INT times(INT x); INT predecessor; INT negated; BL nonNegative; BL isNegative; INT dividedBy(INT x); INT remainder(INT x); BL isOne; literal ST; }; Integer numbers (-1,0,1,2, 100, 3398129, etc.) are precise numbers that are results of counting and enumerating. Integer numbers are discrete, the set of integers is infinite but countable. No arbitrary limit is imposed on the range of integer numbers. Two NULL flavors are defined for the positive and negative infinity. Since the integer number data type includes all of the semantics of the mathematical integer number concept, the basic operations plus (addition) and times (multiplication) are defined. These operations are defined here as characterizing operations in the sense of ISO 11404, and because these operations are needed in other parts of this specification, namely the semantics of the literal form. The traditional recursive definitions of addition and multiplication are due to Grassmann, and use the notion of . H. Grassman. Lehrbuch der Arithmetik. 1861. We prefer Grassman's original axioms to the Peano axioms, because Grassman's axioms work for all integers, not just for natural numbers. Also, "it is rather well-known, through Peano's own acknowledgment, that Peano borrowed his axioms from Dedekind and made extensive use of Grassmann's work in his development of the axioms." (Hao Wang. The Axiomatization of Arithmetic. J. Symb. Logic; 1957:22(2); p. 145.) type IntegerNumber alias INT specializes QTY { INT successor; INT plus(QTY x); INT times(INT x); INT predecessor; INT negated; BL nonNegative; BL isNegative; INT dividedBy(INT x); INT remainder(INT x); BL isOne; literal ST; }; Integer numbers (-1,0,1,2, 100, 3398129, etc.) are precise numbers that are results of counting and enumerating. Integer numbers are discrete, the set of integers is infinite but countable. No arbitrary limit is imposed on the range of integer numbers. Two NULL flavors are defined for the positive and negative infinity. Since the integer number data type includes all of the semantics of the mathematical integer number concept, the basic operations plus (addition) and times (multiplication) are defined. These operations are defined here as characterizing operations in the sense of ISO 11404, and because these operations are needed in other parts of this specification, namely the semantics of the literal form. The traditional recursive definitions of addition and multiplication are due to Grassmann, and use the notion of . H. Grassman. Lehrbuch der Arithmetik. 1861. We prefer Grassman's original axioms to the Peano axioms, because Grassman's axioms work for all integers, not just for natural numbers. Also, "it is rather well-known, through Peano's own acknowledgment, that Peano borrowed his axioms from Dedekind and made extensive use of Grassmann's work in his development of the axioms." (Hao Wang. The Axiomatization of Arithmetic. J. Symb. Logic; 1957:22(2); p. 145.) type IntegerNumber alias INT specializes QTY { INT successor; INT plus(QTY x); INT times(INT x); INT predecessor; INT negated; BL nonNegative; BL isNegative; INT dividedBy(INT x); INT remainder(INT x); BL isOne; literal ST; }; Integer numbers (-1,0,1,2, 100, 3398129, etc.) are precise numbers that are results of counting and enumerating. Integer numbers are discrete, the set of integers is infinite but countable. No arbitrary limit is imposed on the range of integer numbers. Two NULL flavors are defined for the positive and negative infinity. Since the integer number data type includes all of the semantics of the mathematical integer number concept, the basic operations plus (addition) and times (multiplication) are defined. These operations are defined here as characterizing operations in the sense of ISO 11404, and because these operations are needed in other parts of this specification, namely the semantics of the literal form. The traditional recursive definitions of addition and multiplication are due to Grassmann, and use the notion of . H. Grassman. Lehrbuch der Arithmetik. 1861. We prefer Grassman's original axioms to the Peano axioms, because Grassman's axioms work for all integers, not just for natural numbers. Also, "it is rather well-known, through Peano's own acknowledgment, that Peano borrowed his axioms from Dedekind and made extensive use of Grassmann's work in his development of the axioms." (Hao Wang. The Axiomatization of Arithmetic. J. Symb. Logic; 1957:22(2); p. 145.) type IntegerNumber alias INT specializes QTY { INT successor; INT plus(QTY x); INT times(INT x); INT predecessor; INT negated; BL nonNegative; BL isNegative; INT dividedBy(INT x); INT remainder(INT x); BL isOne; literal ST; }; Integer numbers (-1,0,1,2, 100, 3398129, etc.) are precise numbers that are results of counting and enumerating. Integer numbers are discrete, the set of integers is infinite but countable. No arbitrary limit is imposed on the range of integer numbers. Two NULL flavors are defined for the positive and negative infinity. Since the integer number data type includes all of the semantics of the mathematical integer number concept, the basic operations plus (addition) and times (multiplication) are defined. These operations are defined here as characterizing operations in the sense of ISO 11404, and because these operations are needed in other parts of this specification, namely the semantics of the literal form. The traditional recursive definitions of addition and multiplication are due to Grassmann, and use the notion of . H. Grassman. Lehrbuch der Arithmetik. 1861. We prefer Grassman's original axioms to the Peano axioms, because Grassman's axioms work for all integers, not just for natural numbers. Also, "it is rather well-known, through Peano's own acknowledgment, that Peano borrowed his axioms from Dedekind and made extensive use of Grassmann's work in his development of the axioms." (Hao Wang. The Axiomatization of Arithmetic. J. Symb. Logic; 1957:22(2); p. 145.) type IntegerNumber alias INT specializes QTY { INT successor; INT plus(QTY x); INT times(INT x); INT predecessor; INT negated; BL nonNegative; BL isNegative; INT dividedBy(INT x); INT remainder(INT x); BL isOne; literal ST; }; Integer numbers (-1,0,1,2, 100, 3398129, etc.) are precise numbers that are results of counting and enumerating. Integer numbers are discrete, the set of integers is infinite but countable. No arbitrary limit is imposed on the range of integer numbers. Two NULL flavors are defined for the positive and negative infinity. Since the integer number data type includes all of the semantics of the mathematical integer number concept, the basic operations plus (addition) and times (multiplication) are defined. These operations are defined here as characterizing operations in the sense of ISO 11404, and because these operations are needed in other parts of this specification, namely the semantics of the literal form. The traditional recursive definitions of addition and multiplication are due to Grassmann, and use the notion of . H. Grassman. Lehrbuch der Arithmetik. 1861. We prefer Grassman's original axioms to the Peano axioms, because Grassman's axioms work for all integers, not just for natural numbers. Also, "it is rather well-known, through Peano's own acknowledgment, that Peano borrowed his axioms from Dedekind and made extensive use of Grassmann's work in his development of the axioms." (Hao Wang. The Axiomatization of Arithmetic. J. Symb. Logic; 1957:22(2); p. 145.) type IntegerNumber alias INT specializes QTY { INT successor; INT plus(QTY x); INT times(INT x); INT predecessor; INT negated; BL nonNegative; BL isNegative; INT dividedBy(INT x); INT remainder(INT x); BL isOne; literal ST; }; Integer numbers (-1,0,1,2, 100, 3398129, etc.) are precise numbers that are results of counting and enumerating. Integer numbers are discrete, the set of integers is infinite but countable. No arbitrary limit is imposed on the range of integer numbers. Two NULL flavors are defined for the positive and negative infinity. Since the integer number data type includes all of the semantics of the mathematical integer number concept, the basic operations plus (addition) and times (multiplication) are defined. These operations are defined here as characterizing operations in the sense of ISO 11404, and because these operations are needed in other parts of this specification, namely the semantics of the literal form. The traditional recursive definitions of addition and multiplication are due to Grassmann, and use the notion of . H. Grassman. Lehrbuch der Arithmetik. 1861. We prefer Grassman's original axioms to the Peano axioms, because Grassman's axioms work for all integers, not just for natural numbers. Also, "it is rather well-known, through Peano's own acknowledgment, that Peano borrowed his axioms from Dedekind and made extensive use of Grassmann's work in his development of the axioms." (Hao Wang. The Axiomatization of Arithmetic. J. Symb. Logic; 1957:22(2); p. 145.) type IntegerNumber alias INT specializes QTY { INT successor; INT plus(QTY x); INT times(INT x); INT predecessor; INT negated; BL nonNegative; BL isNegative; INT dividedBy(INT x); INT remainder(INT x); BL isOne; literal ST; }; Integer numbers (-1,0,1,2, 100, 3398129, etc.) are precise numbers that are results of counting and enumerating. Integer numbers are discrete, the set of integers is infinite but countable. No arbitrary limit is imposed on the range of integer numbers. Two NULL flavors are defined for the positive and negative infinity. Since the integer number data type includes all of the semantics of the mathematical integer number concept, the basic operations plus (addition) and times (multiplication) are defined. These operations are defined here as characterizing operations in the sense of ISO 11404, and because these operations are needed in other parts of this specification, namely the semantics of the literal form. The traditional recursive definitions of addition and multiplication are due to Grassmann, and use the notion of . H. Grassman. Lehrbuch der Arithmetik. 1861. We prefer Grassman's original axioms to the Peano axioms, because Grassman's axioms work for all integers, not just for natural numbers. Also, "it is rather well-known, through Peano's own acknowledgment, that Peano borrowed his axioms from Dedekind and made extensive use of Grassmann's work in his development of the axioms." (Hao Wang. The Axiomatization of Arithmetic. J. Symb. Logic; 1957:22(2); p. 145.) type IntegerNumber alias INT specializes QTY { INT successor; INT plus(QTY x); INT times(INT x); INT predecessor; INT negated; BL nonNegative; BL isNegative; INT dividedBy(INT x); INT remainder(INT x); BL isOne; literal ST; }; REAL (RealNumber) Fractional numbers. Typically used whenever quantities are measured, estimated, or computed from other real numbers. The typical representation is decimal, where the number of significant decimal digits is known as the precision. The term "Real number" in this specification is used to mean that fractional values are covered without necessarily implying the full set of the mathematical real numbers that would include irrational numbers such as ?, Euler's number, etc. The term "Real" for a fractional number data type originates and is well established in the Algol, Pascal tradition of programming languages. This specification offers two choices for a number data type. The choice is made as follows: Any number attribute is a real if it is not known for sure that it is an integer. A number is an integer if it is always counted, typically representing an ordinal number. If there are conceivable use cases where such a number would be estimated or averaged, it is not always an integer and thus should use the Real data type. The algebraic operations are specified here as characterizing operations in the sense of ISO 11404, and because these operations are needed in other parts of this specification. Unlike the integer numbers, the real numbers semantics are not inductively constructed but only intuitively described by their axioms of their algebraic properties. The completeness axioms are intentionally left out so as to make no statement about irrational numbers. type RealNumber alias REAL specializes QTY { REAL negated; BL isOne; REAL times(REAL x); REAL inverted; REAL power(REAL x); literal ST; INT precision; demotion INT; promotion REAL (INT x); }; Fractional numbers. Typically used whenever quantities are measured, estimated, or computed from other real numbers. The typical representation is decimal, where the number of significant decimal digits is known as the precision. The term "Real number" in this specification is used to mean that fractional values are covered without necessarily implying the full set of the mathematical real numbers that would include irrational numbers such as ?, Euler's number, etc. The term "Real" for a fractional number data type originates and is well established in the Algol, Pascal tradition of programming languages. This specification offers two choices for a number data type. The choice is made as follows: Any number attribute is a real if it is not known for sure that it is an integer. A number is an integer if it is always counted, typically representing an ordinal number. If there are conceivable use cases where such a number would be estimated or averaged, it is not always an integer and thus should use the Real data type. The algebraic operations are specified here as characterizing operations in the sense of ISO 11404, and because these operations are needed in other parts of this specification. Unlike the integer numbers, the real numbers semantics are not inductively constructed but only intuitively described by their axioms of their algebraic properties. The completeness axioms are intentionally left out so as to make no statement about irrational numbers. type RealNumber alias REAL specializes QTY { REAL negated; BL isOne; REAL times(REAL x); REAL inverted; REAL power(REAL x); literal ST; INT precision; demotion INT; promotion REAL (INT x); }; Fractional numbers. Typically used whenever quantities are measured, estimated, or computed from other real numbers. The typical representation is decimal, where the number of significant decimal digits is known as the precision. The term "Real number" in this specification is used to mean that fractional values are covered without necessarily implying the full set of the mathematical real numbers that would include irrational numbers such as ?, Euler's number, etc. The term "Real" for a fractional number data type originates and is well established in the Algol, Pascal tradition of programming languages. This specification offers two choices for a number data type. The choice is made as follows: Any number attribute is a real if it is not known for sure that it is an integer. A number is an integer if it is always counted, typically representing an ordinal number. If there are conceivable use cases where such a number would be estimated or averaged, it is not always an integer and thus should use the Real data type. The algebraic operations are specified here as characterizing operations in the sense of ISO 11404, and because these operations are needed in other parts of this specification. Unlike the integer numbers, the real numbers semantics are not inductively constructed but only intuitively described by their axioms of their algebraic properties. The completeness axioms are intentionally left out so as to make no statement about irrational numbers. type RealNumber alias REAL specializes QTY { REAL negated; BL isOne; REAL times(REAL x); REAL inverted; REAL power(REAL x); literal ST; INT precision; demotion INT; promotion REAL (INT x); }; Fractional numbers. Typically used whenever quantities are measured, estimated, or computed from other real numbers. The typical representation is decimal, where the number of significant decimal digits is known as the precision. The term "Real number" in this specification is used to mean that fractional values are covered without necessarily implying the full set of the mathematical real numbers that would include irrational numbers such as ?, Euler's number, etc. The term "Real" for a fractional number data type originates and is well established in the Algol, Pascal tradition of programming languages. This specification offers two choices for a number data type. The choice is made as follows: Any number attribute is a real if it is not known for sure that it is an integer. A number is an integer if it is always counted, typically representing an ordinal number. If there are conceivable use cases where such a number would be estimated or averaged, it is not always an integer and thus should use the Real data type. The algebraic operations are specified here as characterizing operations in the sense of ISO 11404, and because these operations are needed in other parts of this specification. Unlike the integer numbers, the real numbers semantics are not inductively constructed but only intuitively described by their axioms of their algebraic properties. The completeness axioms are intentionally left out so as to make no statement about irrational numbers. type RealNumber alias REAL specializes QTY { REAL negated; BL isOne; REAL times(REAL x); REAL inverted; REAL power(REAL x); literal ST; INT precision; demotion INT; promotion REAL (INT x); }; Fractional numbers. Typically used whenever quantities are measured, estimated, or computed from other real numbers. The typical representation is decimal, where the number of significant decimal digits is known as the precision. The term "Real number" in this specification is used to mean that fractional values are covered without necessarily implying the full set of the mathematical real numbers that would include irrational numbers such as ?, Euler's number, etc. The term "Real" for a fractional number data type originates and is well established in the Algol, Pascal tradition of programming languages. This specification offers two choices for a number data type. The choice is made as follows: Any number attribute is a real if it is not known for sure that it is an integer. A number is an integer if it is always counted, typically representing an ordinal number. If there are conceivable use cases where such a number would be estimated or averaged, it is not always an integer and thus should use the Real data type. The algebraic operations are specified here as characterizing operations in the sense of ISO 11404, and because these operations are needed in other parts of this specification. Unlike the integer numbers, the real numbers semantics are not inductively constructed but only intuitively described by their axioms of their algebraic properties. The completeness axioms are intentionally left out so as to make no statement about irrational numbers. type RealNumber alias REAL specializes QTY { REAL negated; BL isOne; REAL times(REAL x); REAL inverted; REAL power(REAL x); literal ST; INT precision; demotion INT; promotion REAL (INT x); }; Fractional numbers. Typically used whenever quantities are measured, estimated, or computed from other real numbers. The typical representation is decimal, where the number of significant decimal digits is known as the precision. The term "Real number" in this specification is used to mean that fractional values are covered without necessarily implying the full set of the mathematical real numbers that would include irrational numbers such as ?, Euler's number, etc. The term "Real" for a fractional number data type originates and is well established in the Algol, Pascal tradition of programming languages. This specification offers two choices for a number data type. The choice is made as follows: Any number attribute is a real if it is not known for sure that it is an integer. A number is an integer if it is always counted, typically representing an ordinal number. If there are conceivable use cases where such a number would be estimated or averaged, it is not always an integer and thus should use the Real data type. The algebraic operations are specified here as characterizing operations in the sense of ISO 11404, and because these operations are needed in other parts of this specification. Unlike the integer numbers, the real numbers semantics are not inductively constructed but only intuitively described by their axioms of their algebraic properties. The completeness axioms are intentionally left out so as to make no statement about irrational numbers. type RealNumber alias REAL specializes QTY { REAL negated; BL isOne; REAL times(REAL x); REAL inverted; REAL power(REAL x); literal ST; INT precision; demotion INT; promotion REAL (INT x); }; Fractional numbers. Typically used whenever quantities are measured, estimated, or computed from other real numbers. The typical representation is decimal, where the number of significant decimal digits is known as the precision. The term "Real number" in this specification is used to mean that fractional values are covered without necessarily implying the full set of the mathematical real numbers that would include irrational numbers such as ?, Euler's number, etc. The term "Real" for a fractional number data type originates and is well established in the Algol, Pascal tradition of programming languages. This specification offers two choices for a number data type. The choice is made as follows: Any number attribute is a real if it is not known for sure that it is an integer. A number is an integer if it is always counted, typically representing an ordinal number. If there are conceivable use cases where such a number would be estimated or averaged, it is not always an integer and thus should use the Real data type. The algebraic operations are specified here as characterizing operations in the sense of ISO 11404, and because these operations are needed in other parts of this specification. Unlike the integer numbers, the real numbers semantics are not inductively constructed but only intuitively described by their axioms of their algebraic properties. The completeness axioms are intentionally left out so as to make no statement about irrational numbers. type RealNumber alias REAL specializes QTY { REAL negated; BL isOne; REAL times(REAL x); REAL inverted; REAL power(REAL x); literal ST; INT precision; demotion INT; promotion REAL (INT x); }; Fractional numbers. Typically used whenever quantities are measured, estimated, or computed from other real numbers. The typical representation is decimal, where the number of significant decimal digits is known as the precision. The term "Real number" in this specification is used to mean that fractional values are covered without necessarily implying the full set of the mathematical real numbers that would include irrational numbers such as ?, Euler's number, etc. The term "Real" for a fractional number data type originates and is well established in the Algol, Pascal tradition of programming languages. This specification offers two choices for a number data type. The choice is made as follows: Any number attribute is a real if it is not known for sure that it is an integer. A number is an integer if it is always counted, typically representing an ordinal number. If there are conceivable use cases where such a number would be estimated or averaged, it is not always an integer and thus should use the Real data type. The algebraic operations are specified here as characterizing operations in the sense of ISO 11404, and because these operations are needed in other parts of this specification. Unlike the integer numbers, the real numbers semantics are not inductively constructed but only intuitively described by their axioms of their algebraic properties. The completeness axioms are intentionally left out so as to make no statement about irrational numbers. type RealNumber alias REAL specializes QTY { REAL negated; BL isOne; REAL times(REAL x); REAL inverted; REAL power(REAL x); literal ST; INT precision; demotion INT; promotion REAL (INT x); }; Fractional numbers. Typically used whenever quantities are measured, estimated, or computed from other real numbers. The typical representation is decimal, where the number of significant decimal digits is known as the precision. The term "Real number" in this specification is used to mean that fractional values are covered without necessarily implying the full set of the mathematical real numbers that would include irrational numbers such as ?, Euler's number, etc. The term "Real" for a fractional number data type originates and is well established in the Algol, Pascal tradition of programming languages. This specification offers two choices for a number data type. The choice is made as follows: Any number attribute is a real if it is not known for sure that it is an integer. A number is an integer if it is always counted, typically representing an ordinal number. If there are conceivable use cases where such a number would be estimated or averaged, it is not always an integer and thus should use the Real data type. The algebraic operations are specified here as characterizing operations in the sense of ISO 11404, and because these operations are needed in other parts of this specification. Unlike the integer numbers, the real numbers semantics are not inductively constructed but only intuitively described by their axioms of their algebraic properties. The completeness axioms are intentionally left out so as to make no statement about irrational numbers. type RealNumber alias REAL specializes QTY { REAL negated; BL isOne; REAL times(REAL x); REAL inverted; REAL power(REAL x); literal ST; INT precision; demotion INT; promotion REAL (INT x); }; Fractional numbers. Typically used whenever quantities are measured, estimated, or computed from other real numbers. The typical representation is decimal, where the number of significant decimal digits is known as the precision. The term "Real number" in this specification is used to mean that fractional values are covered without necessarily implying the full set of the mathematical real numbers that would include irrational numbers such as ?, Euler's number, etc. The term "Real" for a fractional number data type originates and is well established in the Algol, Pascal tradition of programming languages. This specification offers two choices for a number data type. The choice is made as follows: Any number attribute is a real if it is not known for sure that it is an integer. A number is an integer if it is always counted, typically representing an ordinal number. If there are conceivable use cases where such a number would be estimated or averaged, it is not always an integer and thus should use the Real data type. The algebraic operations are specified here as characterizing operations in the sense of ISO 11404, and because these operations are needed in other parts of this specification. Unlike the integer numbers, the real numbers semantics are not inductively constructed but only intuitively described by their axioms of their algebraic properties. The completeness axioms are intentionally left out so as to make no statement about irrational numbers. type RealNumber alias REAL specializes QTY { REAL negated; BL isOne; REAL times(REAL x); REAL inverted; REAL power(REAL x); literal ST; INT precision; demotion INT; promotion REAL (INT x); }; Fractional numbers. Typically used whenever quantities are measured, estimated, or computed from other real numbers. The typical representation is decimal, where the number of significant decimal digits is known as the precision. The term "Real number" in this specification is used to mean that fractional values are covered without necessarily implying the full set of the mathematical real numbers that would include irrational numbers such as ?, Euler's number, etc. The term "Real" for a fractional number data type originates and is well established in the Algol, Pascal tradition of programming languages. This specification offers two choices for a number data type. The choice is made as follows: Any number attribute is a real if it is not known for sure that it is an integer. A number is an integer if it is always counted, typically representing an ordinal number. If there are conceivable use cases where such a number would be estimated or averaged, it is not always an integer and thus should use the Real data type. The algebraic operations are specified here as characterizing operations in the sense of ISO 11404, and because these operations are needed in other parts of this specification. Unlike the integer numbers, the real numbers semantics are not inductively constructed but only intuitively described by their axioms of their algebraic properties. The completeness axioms are intentionally left out so as to make no statement about irrational numbers. type RealNumber alias REAL specializes QTY { REAL negated; BL isOne; REAL times(REAL x); REAL inverted; REAL power(REAL x); literal ST; INT precision; demotion INT; promotion REAL (INT x); }; Fractional numbers. Typically used whenever quantities are measured, estimated, or computed from other real numbers. The typical representation is decimal, where the number of significant decimal digits is known as the precision. The term "Real number" in this specification is used to mean that fractional values are covered without necessarily implying the full set of the mathematical real numbers that would include irrational numbers such as ?, Euler's number, etc. The term "Real" for a fractional number data type originates and is well established in the Algol, Pascal tradition of programming languages. This specification offers two choices for a number data type. The choice is made as follows: Any number attribute is a real if it is not known for sure that it is an integer. A number is an integer if it is always counted, typically representing an ordinal number. If there are conceivable use cases where such a number would be estimated or averaged, it is not always an integer and thus should use the Real data type. The algebraic operations are specified here as characterizing operations in the sense of ISO 11404, and because these operations are needed in other parts of this specification. Unlike the integer numbers, the real numbers semantics are not inductively constructed but only intuitively described by their axioms of their algebraic properties. The completeness axioms are intentionally left out so as to make no statement about irrational numbers. type RealNumber alias REAL specializes QTY { REAL negated; BL isOne; REAL times(REAL x); REAL inverted; REAL power(REAL x); literal ST; INT precision; demotion INT; promotion REAL (INT x); }; Fractional numbers. Typically used whenever quantities are measured, estimated, or computed from other real numbers. The typical representation is decimal, where the number of significant decimal digits is known as the precision. The term "Real number" in this specification is used to mean that fractional values are covered without necessarily implying the full set of the mathematical real numbers that would include irrational numbers such as ?, Euler's number, etc. The term "Real" for a fractional number data type originates and is well established in the Algol, Pascal tradition of programming languages. This specification offers two choices for a number data type. The choice is made as follows: Any number attribute is a real if it is not known for sure that it is an integer. A number is an integer if it is always counted, typically representing an ordinal number. If there are conceivable use cases where such a number would be estimated or averaged, it is not always an integer and thus should use the Real data type. The algebraic operations are specified here as characterizing operations in the sense of ISO 11404, and because these operations are needed in other parts of this specification. Unlike the integer numbers, the real numbers semantics are not inductively constructed but only intuitively described by their axioms of their algebraic properties. The completeness axioms are intentionally left out so as to make no statement about irrational numbers. type RealNumber alias REAL specializes QTY { REAL negated; BL isOne; REAL times(REAL x); REAL inverted; REAL power(REAL x); literal ST; INT precision; demotion INT; promotion REAL (INT x); }; RTO (Ratio) A quantity constructed as the quotient of a numerator quantity divided by a denominator quantity. Common factors in the numerator and denominator are not automatically cancelled out. The data type supports titers (e.g., "1:128") and other quantities produced by laboratories that truly represent ratios. Ratios are not simply "structured numerics", particularly blood pressure measurements (e.g. "120/60") are not ratios. In many cases the should be used instead of the . Ratios are different from rational numbers, i.e., in ratios common factors in the numerator and denominator never cancel out. A ratio of two real or integer numbers is not automatically reduced to a real number. The default value for both numerator and denominator is the integer number 1 (one.) The denominator may not be zero. template<QTY N, QTY D> type Ratio<N, D> alias RTO<N, D> specializes QTY { N numerator; D denominator; literal ST; }; A quantity constructed as the quotient of a numerator quantity divided by a denominator quantity. Common factors in the numerator and denominator are not automatically cancelled out. The data type supports titers (e.g., "1:128") and other quantities produced by laboratories that truly represent ratios. Ratios are not simply "structured numerics", particularly blood pressure measurements (e.g. "120/60") are not ratios. In many cases the should be used instead of the . Ratios are different from rational numbers, i.e., in ratios common factors in the numerator and denominator never cancel out. A ratio of two real or integer numbers is not automatically reduced to a real number. The default value for both numerator and denominator is the integer number 1 (one.) The denominator may not be zero. template<QTY N, QTY D> type Ratio<N, D> alias RTO<N, D> specializes QTY { N numerator; D denominator; literal ST; }; A quantity constructed as the quotient of a numerator quantity divided by a denominator quantity. Common factors in the numerator and denominator are not automatically cancelled out. The data type supports titers (e.g., "1:128") and other quantities produced by laboratories that truly represent ratios. Ratios are not simply "structured numerics", particularly blood pressure measurements (e.g. "120/60") are not ratios. In many cases the should be used instead of the . Ratios are different from rational numbers, i.e., in ratios common factors in the numerator and denominator never cancel out. A ratio of two real or integer numbers is not automatically reduced to a real number. The default value for both numerator and denominator is the integer number 1 (one.) The denominator may not be zero. template<QTY N, QTY D> type Ratio<N, D> alias RTO<N, D> specializes QTY { N numerator; D denominator; literal ST; }; A quantity constructed as the quotient of a numerator quantity divided by a denominator quantity. Common factors in the numerator and denominator are not automatically cancelled out. The data type supports titers (e.g., "1:128") and other quantities produced by laboratories that truly represent ratios. Ratios are not simply "structured numerics", particularly blood pressure measurements (e.g. "120/60") are not ratios. In many cases the should be used instead of the . Ratios are different from rational numbers, i.e., in ratios common factors in the numerator and denominator never cancel out. A ratio of two real or integer numbers is not automatically reduced to a real number. The default value for both numerator and denominator is the integer number 1 (one.) The denominator may not be zero. template<QTY N, QTY D> type Ratio<N, D> alias RTO<N, D> specializes QTY { N numerator; D denominator; literal ST; }; PQ (PhysicalQuantity) A dimensioned quantity expressing the result of measuring. type PhysicalQuantity alias PQ specializes QTY { REAL value; CS unit; SET<PQR> translation; PQ canonical; BL isOne; PQ times(PQ x); PQ times(REAL x); PQ inverted; PQ power(INT x); PQ plus(QTY x); literal ST; demotion REAL; }; A dimensioned quantity expressing the result of measuring. type PhysicalQuantity alias PQ specializes QTY { REAL value; CS unit; SET<PQR> translation; PQ canonical; BL isOne; PQ times(PQ x); PQ times(REAL x); PQ inverted; PQ power(INT x); PQ plus(QTY x); literal ST; demotion REAL; }; A dimensioned quantity expressing the result of measuring. type PhysicalQuantity alias PQ specializes QTY { REAL value; CS unit; SET<PQR> translation; PQ canonical; BL isOne; PQ times(PQ x); PQ times(REAL x); PQ inverted; PQ power(INT x); PQ plus(QTY x); literal ST; demotion REAL; }; A dimensioned quantity expressing the result of measuring. type PhysicalQuantity alias PQ specializes QTY { REAL value; CS unit; SET<PQR> translation; PQ canonical; BL isOne; PQ times(PQ x); PQ times(REAL x); PQ inverted; PQ power(INT x); PQ plus(QTY x); literal ST; demotion REAL; }; A dimensioned quantity expressing the result of measuring. type PhysicalQuantity alias PQ specializes QTY { REAL value; CS unit; SET<PQR> translation; PQ canonical; BL isOne; PQ times(PQ x); PQ times(REAL x); PQ inverted; PQ power(INT x); PQ plus(QTY x); literal ST; demotion REAL; }; A dimensioned quantity expressing the result of measuring. type PhysicalQuantity alias PQ specializes QTY { REAL value; CS unit; SET<PQR> translation; PQ canonical; BL isOne; PQ times(PQ x); PQ times(REAL x); PQ inverted; PQ power(INT x); PQ plus(QTY x); literal ST; demotion REAL; }; A dimensioned quantity expressing the result of measuring. type PhysicalQuantity alias PQ specializes QTY { REAL value; CS unit; SET<PQR> translation; PQ canonical; BL isOne; PQ times(PQ x); PQ times(REAL x); PQ inverted; PQ power(INT x); PQ plus(QTY x); literal ST; demotion REAL; }; A dimensioned quantity expressing the result of measuring. type PhysicalQuantity alias PQ specializes QTY { REAL value; CS unit; SET<PQR> translation; PQ canonical; BL isOne; PQ times(PQ x); PQ times(REAL x); PQ inverted; PQ power(INT x); PQ plus(QTY x); literal ST; demotion REAL; }; A dimensioned quantity expressing the result of measuring. type PhysicalQuantity alias PQ specializes QTY { REAL value; CS unit; SET<PQR> translation; PQ canonical; BL isOne; PQ times(PQ x); PQ times(REAL x); PQ inverted; PQ power(INT x); PQ plus(QTY x); literal ST; demotion REAL; }; A dimensioned quantity expressing the result of measuring. type PhysicalQuantity alias PQ specializes QTY { REAL value; CS unit; SET<PQR> translation; PQ canonical; BL isOne; PQ times(PQ x); PQ times(REAL x); PQ inverted; PQ power(INT x); PQ plus(QTY x); literal ST; demotion REAL; }; A dimensioned quantity expressing the result of measuring. type PhysicalQuantity alias PQ specializes QTY { REAL value; CS unit; SET<PQR> translation; PQ canonical; BL isOne; PQ times(PQ x); PQ times(REAL x); PQ inverted; PQ power(INT x); PQ plus(QTY x); literal ST; demotion REAL; }; A dimensioned quantity expressing the result of measuring. type PhysicalQuantity alias PQ specializes QTY { REAL value; CS unit; SET<PQR> translation; PQ canonical; BL isOne; PQ times(PQ x); PQ times(REAL x); PQ inverted; PQ power(INT x); PQ plus(QTY x); literal ST; demotion REAL; }; A dimensioned quantity expressing the result of measuring. type PhysicalQuantity alias PQ specializes QTY { REAL value; CS unit; SET<PQR> translation; PQ canonical; BL isOne; PQ times(PQ x); PQ times(REAL x); PQ inverted; PQ power(INT x); PQ plus(QTY x); literal ST; demotion REAL; }; A dimensioned quantity expressing the result of measuring. type PhysicalQuantity alias PQ specializes QTY { REAL value; CS unit; SET<PQR> translation; PQ canonical; BL isOne; PQ times(PQ x); PQ times(REAL x); PQ inverted; PQ power(INT x); PQ plus(QTY x); literal ST; demotion REAL; }; A dimensioned quantity expressing the result of measuring. type PhysicalQuantity alias PQ specializes QTY { REAL value; CS unit; SET<PQR> translation; PQ canonical; BL isOne; PQ times(PQ x); PQ times(REAL x); PQ inverted; PQ power(INT x); PQ plus(QTY x); literal ST; demotion REAL; }; A dimensioned quantity expressing the result of measuring. type PhysicalQuantity alias PQ specializes QTY { REAL value; CS unit; SET<PQR> translation; PQ canonical; BL isOne; PQ times(PQ x); PQ times(REAL x); PQ inverted; PQ power(INT x); PQ plus(QTY x); literal ST; demotion REAL; }; PQR (PhysicalQuantityRepresentation) An extension of the coded value data type representating a physical quantity using a unit from any code system. Used to show alternative representation for a physical quantity. protected type PhysicalQuantityRepresentation alias PQR specializes CV { REAL value; }; An extension of the coded value data type representating a physical quantity using a unit from any code system. Used to show alternative representation for a physical quantity. protected type PhysicalQuantityRepresentation alias PQR specializes CV { REAL value; }; An extension of the coded value data type representating a physical quantity using a unit from any code system. Used to show alternative representation for a physical quantity. protected type PhysicalQuantityRepresentation alias PQR specializes CV { REAL value; }; An extension of the coded value data type representating a physical quantity using a unit from any code system. Used to show alternative representation for a physical quantity. protected type PhysicalQuantityRepresentation alias PQR specializes CV { REAL value; }; An extension of the coded value data type representating a physical quantity using a unit from any code system. Used to show alternative representation for a physical quantity. protected type PhysicalQuantityRepresentation alias PQR specializes CV { REAL value; }; An extension of the coded value data type representating a physical quantity using a unit from any code system. Used to show alternative representation for a physical quantity. protected type PhysicalQuantityRepresentation alias PQR specializes CV { REAL value; }; An extension of the coded value data type representating a physical quantity using a unit from any code system. Used to show alternative representation for a physical quantity. protected type PhysicalQuantityRepresentation alias PQR specializes CV { REAL value; }; An extension of the coded value data type representating a physical quantity using a unit from any code system. Used to show alternative representation for a physical quantity. protected type PhysicalQuantityRepresentation alias PQR specializes CV { REAL value; }; MO (MonetaryAmount) A monetary amount is a quantity expressing the amount of money in some currency. Currencies are the units in which monetary amounts are denominated in different economic regions. While the monetary amount is a single kind of quantity (money) the exchange rates between the different units are variable. This is the principle difference between physical quantity and monetary amounts, and the reason why currency units are not physical units. type MonetaryAmount alias MO specializes QTY { REAL value; CS currency; MO plus(MO x); MO times(REAL x); literal ST; }; A monetary amount is a quantity expressing the amount of money in some currency. Currencies are the units in which monetary amounts are denominated in different economic regions. While the monetary amount is a single kind of quantity (money) the exchange rates between the different units are variable. This is the principle difference between physical quantity and monetary amounts, and the reason why currency units are not physical units. type MonetaryAmount alias MO specializes QTY { REAL value; CS currency; MO plus(MO x); MO times(REAL x); literal ST; }; A monetary amount is a quantity expressing the amount of money in some currency. Currencies are the units in which monetary amounts are denominated in different economic regions. While the monetary amount is a single kind of quantity (money) the exchange rates between the different units are variable. This is the principle difference between physical quantity and monetary amounts, and the reason why currency units are not physical units. type MonetaryAmount alias MO specializes QTY { REAL value; CS currency; MO plus(MO x); MO times(REAL x); literal ST; }; A monetary amount is a quantity expressing the amount of money in some currency. Currencies are the units in which monetary amounts are denominated in different economic regions. While the monetary amount is a single kind of quantity (money) the exchange rates between the different units are variable. This is the principle difference between physical quantity and monetary amounts, and the reason why currency units are not physical units. type MonetaryAmount alias MO specializes QTY { REAL value; CS currency; MO plus(MO x); MO times(REAL x); literal ST; }; A monetary amount is a quantity expressing the amount of money in some currency. Currencies are the units in which monetary amounts are denominated in different economic regions. While the monetary amount is a single kind of quantity (money) the exchange rates between the different units are variable. This is the principle difference between physical quantity and monetary amounts, and the reason why currency units are not physical units. type MonetaryAmount alias MO specializes QTY { REAL value; CS currency; MO plus(MO x); MO times(REAL x); literal ST; }; A monetary amount is a quantity expressing the amount of money in some currency. Currencies are the units in which monetary amounts are denominated in different economic regions. While the monetary amount is a single kind of quantity (money) the exchange rates between the different units are variable. This is the principle difference between physical quantity and monetary amounts, and the reason why currency units are not physical units. type MonetaryAmount alias MO specializes QTY { REAL value; CS currency; MO plus(MO x); MO times(REAL x); literal ST; }; A monetary amount is a quantity expressing the amount of money in some currency. Currencies are the units in which monetary amounts are denominated in different economic regions. While the monetary amount is a single kind of quantity (money) the exchange rates between the different units are variable. This is the principle difference between physical quantity and monetary amounts, and the reason why currency units are not physical units. type MonetaryAmount alias MO specializes QTY { REAL value; CS currency; MO plus(MO x); MO times(REAL x); literal ST; }; A monetary amount is a quantity expressing the amount of money in some currency. Currencies are the units in which monetary amounts are denominated in different economic regions. While the monetary amount is a single kind of quantity (money) the exchange rates between the different units are variable. This is the principle difference between physical quantity and monetary amounts, and the reason why currency units are not physical units. type MonetaryAmount alias MO specializes QTY { REAL value; CS currency; MO plus(MO x); MO times(REAL x); literal ST; }; A monetary amount is a quantity expressing the amount of money in some currency. Currencies are the units in which monetary amounts are denominated in different economic regions. While the monetary amount is a single kind of quantity (money) the exchange rates between the different units are variable. This is the principle difference between physical quantity and monetary amounts, and the reason why currency units are not physical units. type MonetaryAmount alias MO specializes QTY { REAL value; CS currency; MO plus(MO x); MO times(REAL x); literal ST; }; CAL (Calendar) A calendar is a concept of measuring time in various cycles. Such cycles are years, months, days, hours, minutes, seconds, and weeks. Some of these cycles are synchronized and some are not (e.g., weeks and months are not synchronized.) After "rolling the time axis" into these cycles (See the figure) a calendar expresses a point in time as a sequence of integer counts of cycles, e.g., for year, month, day, hour, etc. The calendar is rooted in some conventional start point, called the "epoch." A calendar "rolls" the time axis into a complex convolute according to the calendar periods year (blue), month (yellow), day (green), hour (red), etc. The cycles need not be aligned, for example, the week (not shown) is not aligned to the month. Imagine a special clock that measures those cycles, where the pointers are not all stacked on a common axis but each pointer is attached to the end of the pointer measuring the next larger cycle. Calendar is defined as a set of calendar cycles, and has a name and a code. The head of the Calendar is the largest CalendarCycle appearing right most in the calendar expression. The epoch is the beginning of that calendar, i.e., the point in time where all calendar cycles are zero. The calendar definition can be shown as in for the modern Gregorian calendar. The calendar definition table lists a calendar cycle in each row. The calendar units are dependent on each other and defined in the value column. The sequence column shows the relationship through the next property. The other columns are as in the formal calendar cycle definition. At present, the CalendarCycle properties sum and value are not formally defined. The computation of calendar digits involves some complex computation which to specify here would be hard to understand and evaluate for correctness. Unfortunately, no standard exists that would formally define the relationship between calendar expressions and elapsed time since an epoch. ASN.1, the XML Schema Data Type specification and SQL92 all refer to ISO 8601, however, ISO 8601 does only specify the syntax of Gregorian calendar expressions, but not their semantics. In this standard, we define the syntax and semantics formally, however, we presume the semantics of the sum-, and value-properties to be defined elsewhere. private type Calendar alias CAL specializes SET<CLCY> { CS name; CLCY head; TS epoch; }; A calendar is a concept of measuring time in various cycles. Such cycles are years, months, days, hours, minutes, seconds, and weeks. Some of these cycles are synchronized and some are not (e.g., weeks and months are not synchronized.) After "rolling the time axis" into these cycles (See the figure) a calendar expresses a point in time as a sequence of integer counts of cycles, e.g., for year, month, day, hour, etc. The calendar is rooted in some conventional start point, called the "epoch." A calendar "rolls" the time axis into a complex convolute according to the calendar periods year (blue), month (yellow), day (green), hour (red), etc. The cycles need not be aligned, for example, the week (not shown) is not aligned to the month. Imagine a special clock that measures those cycles, where the pointers are not all stacked on a common axis but each pointer is attached to the end of the pointer measuring the next larger cycle. Calendar is defined as a set of calendar cycles, and has a name and a code. The head of the Calendar is the largest CalendarCycle appearing right most in the calendar expression. The epoch is the beginning of that calendar, i.e., the point in time where all calendar cycles are zero. The calendar definition can be shown as in for the modern Gregorian calendar. The calendar definition table lists a calendar cycle in each row. The calendar units are dependent on each other and defined in the value column. The sequence column shows the relationship through the next property. The other columns are as in the formal calendar cycle definition. At present, the CalendarCycle properties sum and value are not formally defined. The computation of calendar digits involves some complex computation which to specify here would be hard to understand and evaluate for correctness. Unfortunately, no standard exists that would formally define the relationship between calendar expressions and elapsed time since an epoch. ASN.1, the XML Schema Data Type specification and SQL92 all refer to ISO 8601, however, ISO 8601 does only specify the syntax of Gregorian calendar expressions, but not their semantics. In this standard, we define the syntax and semantics formally, however, we presume the semantics of the sum-, and value-properties to be defined elsewhere. private type Calendar alias CAL specializes SET<CLCY> { CS name; CLCY head; TS epoch; }; A calendar is a concept of measuring time in various cycles. Such cycles are years, months, days, hours, minutes, seconds, and weeks. Some of these cycles are synchronized and some are not (e.g., weeks and months are not synchronized.) After "rolling the time axis" into these cycles (See the figure) a calendar expresses a point in time as a sequence of integer counts of cycles, e.g., for year, month, day, hour, etc. The calendar is rooted in some conventional start point, called the "epoch." A calendar "rolls" the time axis into a complex convolute according to the calendar periods year (blue), month (yellow), day (green), hour (red), etc. The cycles need not be aligned, for example, the week (not shown) is not aligned to the month. Imagine a special clock that measures those cycles, where the pointers are not all stacked on a common axis but each pointer is attached to the end of the pointer measuring the next larger cycle. Calendar is defined as a set of calendar cycles, and has a name and a code. The head of the Calendar is the largest CalendarCycle appearing right most in the calendar expression. The epoch is the beginning of that calendar, i.e., the point in time where all calendar cycles are zero. The calendar definition can be shown as in for the modern Gregorian calendar. The calendar definition table lists a calendar cycle in each row. The calendar units are dependent on each other and defined in the value column. The sequence column shows the relationship through the next property. The other columns are as in the formal calendar cycle definition. At present, the CalendarCycle properties sum and value are not formally defined. The computation of calendar digits involves some complex computation which to specify here would be hard to understand and evaluate for correctness. Unfortunately, no standard exists that would formally define the relationship between calendar expressions and elapsed time since an epoch. ASN.1, the XML Schema Data Type specification and SQL92 all refer to ISO 8601, however, ISO 8601 does only specify the syntax of Gregorian calendar expressions, but not their semantics. In this standard, we define the syntax and semantics formally, however, we presume the semantics of the sum-, and value-properties to be defined elsewhere. private type Calendar alias CAL specializes SET<CLCY> { CS name; CLCY head; TS epoch; }; A calendar is a concept of measuring time in various cycles. Such cycles are years, months, days, hours, minutes, seconds, and weeks. Some of these cycles are synchronized and some are not (e.g., weeks and months are not synchronized.) After "rolling the time axis" into these cycles (See the figure) a calendar expresses a point in time as a sequence of integer counts of cycles, e.g., for year, month, day, hour, etc. The calendar is rooted in some conventional start point, called the "epoch." A calendar "rolls" the time axis into a complex convolute according to the calendar periods year (blue), month (yellow), day (green), hour (red), etc. The cycles need not be aligned, for example, the week (not shown) is not aligned to the month. Imagine a special clock that measures those cycles, where the pointers are not all stacked on a common axis but each pointer is attached to the end of the pointer measuring the next larger cycle. Calendar is defined as a set of calendar cycles, and has a name and a code. The head of the Calendar is the largest CalendarCycle appearing right most in the calendar expression. The epoch is the beginning of that calendar, i.e., the point in time where all calendar cycles are zero. The calendar definition can be shown as in for the modern Gregorian calendar. The calendar definition table lists a calendar cycle in each row. The calendar units are dependent on each other and defined in the value column. The sequence column shows the relationship through the next property. The other columns are as in the formal calendar cycle definition. At present, the CalendarCycle properties sum and value are not formally defined. The computation of calendar digits involves some complex computation which to specify here would be hard to understand and evaluate for correctness. Unfortunately, no standard exists that would formally define the relationship between calendar expressions and elapsed time since an epoch. ASN.1, the XML Schema Data Type specification and SQL92 all refer to ISO 8601, however, ISO 8601 does only specify the syntax of Gregorian calendar expressions, but not their semantics. In this standard, we define the syntax and semantics formally, however, we presume the semantics of the sum-, and value-properties to be defined elsewhere. private type Calendar alias CAL specializes SET<CLCY> { CS name; CLCY head; TS epoch; }; A calendar is a concept of measuring time in various cycles. Such cycles are years, months, days, hours, minutes, seconds, and weeks. Some of these cycles are synchronized and some are not (e.g., weeks and months are not synchronized.) After "rolling the time axis" into these cycles (See the figure) a calendar expresses a point in time as a sequence of integer counts of cycles, e.g., for year, month, day, hour, etc. The calendar is rooted in some conventional start point, called the "epoch." A calendar "rolls" the time axis into a complex convolute according to the calendar periods year (blue), month (yellow), day (green), hour (red), etc. The cycles need not be aligned, for example, the week (not shown) is not aligned to the month. Imagine a special clock that measures those cycles, where the pointers are not all stacked on a common axis but each pointer is attached to the end of the pointer measuring the next larger cycle. Calendar is defined as a set of calendar cycles, and has a name and a code. The head of the Calendar is the largest CalendarCycle appearing right most in the calendar expression. The epoch is the beginning of that calendar, i.e., the point in time where all calendar cycles are zero. The calendar definition can be shown as in for the modern Gregorian calendar. The calendar definition table lists a calendar cycle in each row. The calendar units are dependent on each other and defined in the value column. The sequence column shows the relationship through the next property. The other columns are as in the formal calendar cycle definition. At present, the CalendarCycle properties sum and value are not formally defined. The computation of calendar digits involves some complex computation which to specify here would be hard to understand and evaluate for correctness. Unfortunately, no standard exists that would formally define the relationship between calendar expressions and elapsed time since an epoch. ASN.1, the XML Schema Data Type specification and SQL92 all refer to ISO 8601, however, ISO 8601 does only specify the syntax of Gregorian calendar expressions, but not their semantics. In this standard, we define the syntax and semantics formally, however, we presume the semantics of the sum-, and value-properties to be defined elsewhere. private type Calendar alias CAL specializes SET<CLCY> { CS name; CLCY head; TS epoch; }; CLCY (CalendarCycle) A calendar cycle defines one group of decimal digits in the calendar expression. Examples for calendar cycles are year, month, day, hour, minute, second, and week. A calendar cycle has a name and two codes, a one-letter code and a two-letter code. The property ndigits is the number of decimal digits occupied in the calendar expression. The property start specifies where counting starts (i.e., at 0 or 1.) The next property is the next lower cycle in the order of the calendar expression. The max(t) property is the maximum number of cycles at time t (max depends on the time t to account for leap years and leap seconds.) The property value(t) is the integer number of cycles shown in the calendar expression of time t. The property sum(t, n) is the sum of n calendar cycles added to the time t. private type CalendarCycle alias CLCY specializes ANY { CE name; INT ndigits; INT start; CLCY next; INT max(TS t); TS sum(TS t, REAL r); INT value(TS t); }; A calendar cycle defines one group of decimal digits in the calendar expression. Examples for calendar cycles are year, month, day, hour, minute, second, and week. A calendar cycle has a name and two codes, a one-letter code and a two-letter code. The property ndigits is the number of decimal digits occupied in the calendar expression. The property start specifies where counting starts (i.e., at 0 or 1.) The next property is the next lower cycle in the order of the calendar expression. The max(t) property is the maximum number of cycles at time t (max depends on the time t to account for leap years and leap seconds.) The property value(t) is the integer number of cycles shown in the calendar expression of time t. The property sum(t, n) is the sum of n calendar cycles added to the time t. private type CalendarCycle alias CLCY specializes ANY { CE name; INT ndigits; INT start; CLCY next; INT max(TS t); TS sum(TS t, REAL r); INT value(TS t); }; A calendar cycle defines one group of decimal digits in the calendar expression. Examples for calendar cycles are year, month, day, hour, minute, second, and week. A calendar cycle has a name and two codes, a one-letter code and a two-letter code. The property ndigits is the number of decimal digits occupied in the calendar expression. The property start specifies where counting starts (i.e., at 0 or 1.) The next property is the next lower cycle in the order of the calendar expression. The max(t) property is the maximum number of cycles at time t (max depends on the time t to account for leap years and leap seconds.) The property value(t) is the integer number of cycles shown in the calendar expression of time t. The property sum(t, n) is the sum of n calendar cycles added to the time t. private type CalendarCycle alias CLCY specializes ANY { CE name; INT ndigits; INT start; CLCY next; INT max(TS t); TS sum(TS t, REAL r); INT value(TS t); }; A calendar cycle defines one group of decimal digits in the calendar expression. Examples for calendar cycles are year, month, day, hour, minute, second, and week. A calendar cycle has a name and two codes, a one-letter code and a two-letter code. The property ndigits is the number of decimal digits occupied in the calendar expression. The property start specifies where counting starts (i.e., at 0 or 1.) The next property is the next lower cycle in the order of the calendar expression. The max(t) property is the maximum number of cycles at time t (max depends on the time t to account for leap years and leap seconds.) The property value(t) is the integer number of cycles shown in the calendar expression of time t. The property sum(t, n) is the sum of n calendar cycles added to the time t. private type CalendarCycle alias CLCY specializes ANY { CE name; INT ndigits; INT start; CLCY next; INT max(TS t); TS sum(TS t, REAL r); INT value(TS t); }; A calendar cycle defines one group of decimal digits in the calendar expression. Examples for calendar cycles are year, month, day, hour, minute, second, and week. A calendar cycle has a name and two codes, a one-letter code and a two-letter code. The property ndigits is the number of decimal digits occupied in the calendar expression. The property start specifies where counting starts (i.e., at 0 or 1.) The next property is the next lower cycle in the order of the calendar expression. The max(t) property is the maximum number of cycles at time t (max depends on the time t to account for leap years and leap seconds.) The property value(t) is the integer number of cycles shown in the calendar expression of time t. The property sum(t, n) is the sum of n calendar cycles added to the time t. private type CalendarCycle alias CLCY specializes ANY { CE name; INT ndigits; INT start; CLCY next; INT max(TS t); TS sum(TS t, REAL r); INT value(TS t); }; A calendar cycle defines one group of decimal digits in the calendar expression. Examples for calendar cycles are year, month, day, hour, minute, second, and week. A calendar cycle has a name and two codes, a one-letter code and a two-letter code. The property ndigits is the number of decimal digits occupied in the calendar expression. The property start specifies where counting starts (i.e., at 0 or 1.) The next property is the next lower cycle in the order of the calendar expression. The max(t) property is the maximum number of cycles at time t (max depends on the time t to account for leap years and leap seconds.) The property value(t) is the integer number of cycles shown in the calendar expression of time t. The property sum(t, n) is the sum of n calendar cycles added to the time t. private type CalendarCycle alias CLCY specializes ANY { CE name; INT ndigits; INT start; CLCY next; INT max(TS t); TS sum(TS t, REAL r); INT value(TS t); }; A calendar cycle defines one group of decimal digits in the calendar expression. Examples for calendar cycles are year, month, day, hour, minute, second, and week. A calendar cycle has a name and two codes, a one-letter code and a two-letter code. The property ndigits is the number of decimal digits occupied in the calendar expression. The property start specifies where counting starts (i.e., at 0 or 1.) The next property is the next lower cycle in the order of the calendar expression. The max(t) property is the maximum number of cycles at time t (max depends on the time t to account for leap years and leap seconds.) The property value(t) is the integer number of cycles shown in the calendar expression of time t. The property sum(t, n) is the sum of n calendar cycles added to the time t. private type CalendarCycle alias CLCY specializes ANY { CE name; INT ndigits; INT start; CLCY next; INT max(TS t); TS sum(TS t, REAL r); INT value(TS t); }; A calendar cycle defines one group of decimal digits in the calendar expression. Examples for calendar cycles are year, month, day, hour, minute, second, and week. A calendar cycle has a name and two codes, a one-letter code and a two-letter code. The property ndigits is the number of decimal digits occupied in the calendar expression. The property start specifies where counting starts (i.e., at 0 or 1.) The next property is the next lower cycle in the order of the calendar expression. The max(t) property is the maximum number of cycles at time t (max depends on the time t to account for leap years and leap seconds.) The property value(t) is the integer number of cycles shown in the calendar expression of time t. The property sum(t, n) is the sum of n calendar cycles added to the time t. private type CalendarCycle alias CLCY specializes ANY { CE name; INT ndigits; INT start; CLCY next; INT max(TS t); TS sum(TS t, REAL r); INT value(TS t); }; A calendar cycle defines one group of decimal digits in the calendar expression. Examples for calendar cycles are year, month, day, hour, minute, second, and week. A calendar cycle has a name and two codes, a one-letter code and a two-letter code. The property ndigits is the number of decimal digits occupied in the calendar expression. The property start specifies where counting starts (i.e., at 0 or 1.) The next property is the next lower cycle in the order of the calendar expression. The max(t) property is the maximum number of cycles at time t (max depends on the time t to account for leap years and leap seconds.) The property value(t) is the integer number of cycles shown in the calendar expression of time t. The property sum(t, n) is the sum of n calendar cycles added to the time t. private type CalendarCycle alias CLCY specializes ANY { CE name; INT ndigits; INT start; CLCY next; INT max(TS t); TS sum(TS t, REAL r); INT value(TS t); }; TS (PointInTime) A quantity specifying a point on the axis of natural time. A point in time is most often represented as a calendar expression. Semantically, however, time is independent from calendars and best described by its relationship to elapsed time (measured as a physical quantity in the dimension of time.) A point in time plus an elapsed time yields another point in time. Inversely, a point in time minus another point in time yields an elapsed time. As nobody knows when time began, a point in time is conceptualized as the amount of time that has elapsed from some arbitrary zero-point, called an epoch. Because there is no absolute zero-point on the time axis natural time is a difference-scale quantity, where only differences are defined but no ratios. (For example, no point in time is - absolutely speaking - "twice as late" as another point in time.) Given some arbitrary zero-point, one can express any point in time as an elapsed time measured from that offset. Such an arbitrary zero-point is called an epoch. This epoch-offset form is used as a semantic representation here, without implying that any system would have to implement the TS data type in that way. Systems that do not need to compute distances between points in time will not need any other representation than a calendar expression literal. type PointInTime alias TS specializes QTY { PQ offset; CS calendar; INT precision; PQ timezone; TS plus(QTY x); literal ST; }; A quantity specifying a point on the axis of natural time. A point in time is most often represented as a calendar expression. Semantically, however, time is independent from calendars and best described by its relationship to elapsed time (measured as a physical quantity in the dimension of time.) A point in time plus an elapsed time yields another point in time. Inversely, a point in time minus another point in time yields an elapsed time. As nobody knows when time began, a point in time is conceptualized as the amount of time that has elapsed from some arbitrary zero-point, called an epoch. Because there is no absolute zero-point on the time axis natural time is a difference-scale quantity, where only differences are defined but no ratios. (For example, no point in time is - absolutely speaking - "twice as late" as another point in time.) Given some arbitrary zero-point, one can express any point in time as an elapsed time measured from that offset. Such an arbitrary zero-point is called an epoch. This epoch-offset form is used as a semantic representation here, without implying that any system would have to implement the TS data type in that way. Systems that do not need to compute distances between points in time will not need any other representation than a calendar expression literal. type PointInTime alias TS specializes QTY { PQ offset; CS calendar; INT precision; PQ timezone; TS plus(QTY x); literal ST; }; A quantity specifying a point on the axis of natural time. A point in time is most often represented as a calendar expression. Semantically, however, time is independent from calendars and best described by its relationship to elapsed time (measured as a physical quantity in the dimension of time.) A point in time plus an elapsed time yields another point in time. Inversely, a point in time minus another point in time yields an elapsed time. As nobody knows when time began, a point in time is conceptualized as the amount of time that has elapsed from some arbitrary zero-point, called an epoch. Because there is no absolute zero-point on the time axis natural time is a difference-scale quantity, where only differences are defined but no ratios. (For example, no point in time is - absolutely speaking - "twice as late" as another point in time.) Given some arbitrary zero-point, one can express any point in time as an elapsed time measured from that offset. Such an arbitrary zero-point is called an epoch. This epoch-offset form is used as a semantic representation here, without implying that any system would have to implement the TS data type in that way. Systems that do not need to compute distances between points in time will not need any other representation than a calendar expression literal. type PointInTime alias TS specializes QTY { PQ offset; CS calendar; INT precision; PQ timezone; TS plus(QTY x); literal ST; }; A quantity specifying a point on the axis of natural time. A point in time is most often represented as a calendar expression. Semantically, however, time is independent from calendars and best described by its relationship to elapsed time (measured as a physical quantity in the dimension of time.) A point in time plus an elapsed time yields another point in time. Inversely, a point in time minus another point in time yields an elapsed time. As nobody knows when time began, a point in time is conceptualized as the amount of time that has elapsed from some arbitrary zero-point, called an epoch. Because there is no absolute zero-point on the time axis natural time is a difference-scale quantity, where only differences are defined but no ratios. (For example, no point in time is - absolutely speaking - "twice as late" as another point in time.) Given some arbitrary zero-point, one can express any point in time as an elapsed time measured from that offset. Such an arbitrary zero-point is called an epoch. This epoch-offset form is used as a semantic representation here, without implying that any system would have to implement the TS data type in that way. Systems that do not need to compute distances between points in time will not need any other representation than a calendar expression literal. type PointInTime alias TS specializes QTY { PQ offset; CS calendar; INT precision; PQ timezone; TS plus(QTY x); literal ST; }; A quantity specifying a point on the axis of natural time. A point in time is most often represented as a calendar expression. Semantically, however, time is independent from calendars and best described by its relationship to elapsed time (measured as a physical quantity in the dimension of time.) A point in time plus an elapsed time yields another point in time. Inversely, a point in time minus another point in time yields an elapsed time. As nobody knows when time began, a point in time is conceptualized as the amount of time that has elapsed from some arbitrary zero-point, called an epoch. Because there is no absolute zero-point on the time axis natural time is a difference-scale quantity, where only differences are defined but no ratios. (For example, no point in time is - absolutely speaking - "twice as late" as another point in time.) Given some arbitrary zero-point, one can express any point in time as an elapsed time measured from that offset. Such an arbitrary zero-point is called an epoch. This epoch-offset form is used as a semantic representation here, without implying that any system would have to implement the TS data type in that way. Systems that do not need to compute distances between points in time will not need any other representation than a calendar expression literal. type PointInTime alias TS specializes QTY { PQ offset; CS calendar; INT precision; PQ timezone; TS plus(QTY x); literal ST; }; A quantity specifying a point on the axis of natural time. A point in time is most often represented as a calendar expression. Semantically, however, time is independent from calendars and best described by its relationship to elapsed time (measured as a physical quantity in the dimension of time.) A point in time plus an elapsed time yields another point in time. Inversely, a point in time minus another point in time yields an elapsed time. As nobody knows when time began, a point in time is conceptualized as the amount of time that has elapsed from some arbitrary zero-point, called an epoch. Because there is no absolute zero-point on the time axis natural time is a difference-scale quantity, where only differences are defined but no ratios. (For example, no point in time is - absolutely speaking - "twice as late" as another point in time.) Given some arbitrary zero-point, one can express any point in time as an elapsed time measured from that offset. Such an arbitrary zero-point is called an epoch. This epoch-offset form is used as a semantic representation here, without implying that any system would have to implement the TS data type in that way. Systems that do not need to compute distances between points in time will not need any other representation than a calendar expression literal. type PointInTime alias TS specializes QTY { PQ offset; CS calendar; INT precision; PQ timezone; TS plus(QTY x); literal ST; }; A quantity specifying a point on the axis of natural time. A point in time is most often represented as a calendar expression. Semantically, however, time is independent from calendars and best described by its relationship to elapsed time (measured as a physical quantity in the dimension of time.) A point in time plus an elapsed time yields another point in time. Inversely, a point in time minus another point in time yields an elapsed time. As nobody knows when time began, a point in time is conceptualized as the amount of time that has elapsed from some arbitrary zero-point, called an epoch. Because there is no absolute zero-point on the time axis natural time is a difference-scale quantity, where only differences are defined but no ratios. (For example, no point in time is - absolutely speaking - "twice as late" as another point in time.) Given some arbitrary zero-point, one can express any point in time as an elapsed time measured from that offset. Such an arbitrary zero-point is called an epoch. This epoch-offset form is used as a semantic representation here, without implying that any system would have to implement the TS data type in that way. Systems that do not need to compute distances between points in time will not need any other representation than a calendar expression literal. type PointInTime alias TS specializes QTY { PQ offset; CS calendar; INT precision; PQ timezone; TS plus(QTY x); literal ST; }; A quantity specifying a point on the axis of natural time. A point in time is most often represented as a calendar expression. Semantically, however, time is independent from calendars and best described by its relationship to elapsed time (measured as a physical quantity in the dimension of time.) A point in time plus an elapsed time yields another point in time. Inversely, a point in time minus another point in time yields an elapsed time. As nobody knows when time began, a point in time is conceptualized as the amount of time that has elapsed from some arbitrary zero-point, called an epoch. Because there is no absolute zero-point on the time axis natural time is a difference-scale quantity, where only differences are defined but no ratios. (For example, no point in time is - absolutely speaking - "twice as late" as another point in time.) Given some arbitrary zero-point, one can express any point in time as an elapsed time measured from that offset. Such an arbitrary zero-point is called an epoch. This epoch-offset form is used as a semantic representation here, without implying that any system would have to implement the TS data type in that way. Systems that do not need to compute distances between points in time will not need any other representation than a calendar expression literal. type PointInTime alias TS specializes QTY { PQ offset; CS calendar; INT precision; PQ timezone; TS plus(QTY x); literal ST; }; A quantity specifying a point on the axis of natural time. A point in time is most often represented as a calendar expression. Semantically, however, time is independent from calendars and best described by its relationship to elapsed time (measured as a physical quantity in the dimension of time.) A point in time plus an elapsed time yields another point in time. Inversely, a point in time minus another point in time yields an elapsed time. As nobody knows when time began, a point in time is conceptualized as the amount of time that has elapsed from some arbitrary zero-point, called an epoch. Because there is no absolute zero-point on the time axis natural time is a difference-scale quantity, where only differences are defined but no ratios. (For example, no point in time is - absolutely speaking - "twice as late" as another point in time.) Given some arbitrary zero-point, one can express any point in time as an elapsed time measured from that offset. Such an arbitrary zero-point is called an epoch. This epoch-offset form is used as a semantic representation here, without implying that any system would have to implement the TS data type in that way. Systems that do not need to compute distances between points in time will not need any other representation than a calendar expression literal. type PointInTime alias TS specializes QTY { PQ offset; CS calendar; INT precision; PQ timezone; TS plus(QTY x); literal ST; }; A quantity specifying a point on the axis of natural time. A point in time is most often represented as a calendar expression. Semantically, however, time is independent from calendars and best described by its relationship to elapsed time (measured as a physical quantity in the dimension of time.) A point in time plus an elapsed time yields another point in time. Inversely, a point in time minus another point in time yields an elapsed time. As nobody knows when time began, a point in time is conceptualized as the amount of time that has elapsed from some arbitrary zero-point, called an epoch. Because there is no absolute zero-point on the time axis natural time is a difference-scale quantity, where only differences are defined but no ratios. (For example, no point in time is - absolutely speaking - "twice as late" as another point in time.) Given some arbitrary zero-point, one can express any point in time as an elapsed time measured from that offset. Such an arbitrary zero-point is called an epoch. This epoch-offset form is used as a semantic representation here, without implying that any system would have to implement the TS data type in that way. Systems that do not need to compute distances between points in time will not need any other representation than a calendar expression literal. type PointInTime alias TS specializes QTY { PQ offset; CS calendar; INT precision; PQ timezone; TS plus(QTY x); literal ST; }; SET (Set) A value that contains other distinct values in no particular order. template<ANY T> type Set<T> alias SET<T> specializes ANY { BL contains(T element); BL contains(SET<T> subset); BL isEmpty; BL notEmpty; INT cardinality; SET<T> union(SET<T> otherset); SET<T> union(T element); SET<T> except(T element); SET<T> except(SET<T> otherset); SET<T> intersection(SET<T> otherset); literal ST; promotion SET<T> (T x); IVL<T> hull; }; A value that contains other distinct values in no particular order. template<ANY T> type Set<T> alias SET<T> specializes ANY { BL contains(T element); BL contains(SET<T> subset); BL isEmpty; BL notEmpty; INT cardinality; SET<T> union(SET<T> otherset); SET<T> union(T element); SET<T> except(T element); SET<T> except(SET<T> otherset); SET<T> intersection(SET<T> otherset); literal ST; promotion SET<T> (T x); IVL<T> hull; }; A value that contains other distinct values in no particular order. template<ANY T> type Set<T> alias SET<T> specializes ANY { BL contains(T element); BL contains(SET<T> subset); BL isEmpty; BL notEmpty; INT cardinality; SET<T> union(SET<T> otherset); SET<T> union(T element); SET<T> except(T element); SET<T> except(SET<T> otherset); SET<T> intersection(SET<T> otherset); literal ST; promotion SET<T> (T x); IVL<T> hull; }; A value that contains other distinct values in no particular order. template<ANY T> type Set<T> alias SET<T> specializes ANY { BL contains(T element); BL contains(SET<T> subset); BL isEmpty; BL notEmpty; INT cardinality; SET<T> union(SET<T> otherset); SET<T> union(T element); SET<T> except(T element); SET<T> except(SET<T> otherset); SET<T> intersection(SET<T> otherset); literal ST; promotion SET<T> (T x); IVL<T> hull; }; A value that contains other distinct values in no particular order. template<ANY T> type Set<T> alias SET<T> specializes ANY { BL contains(T element); BL contains(SET<T> subset); BL isEmpty; BL notEmpty; INT cardinality; SET<T> union(SET<T> otherset); SET<T> union(T element); SET<T> except(T element); SET<T> except(SET<T> otherset); SET<T> intersection(SET<T> otherset); literal ST; promotion SET<T> (T x); IVL<T> hull; }; A value that contains other distinct values in no particular order. template<ANY T> type Set<T> alias SET<T> specializes ANY { BL contains(T element); BL contains(SET<T> subset); BL isEmpty; BL notEmpty; INT cardinality; SET<T> union(SET<T> otherset); SET<T> union(T element); SET<T> except(T element); SET<T> except(SET<T> otherset); SET<T> intersection(SET<T> otherset); literal ST; promotion SET<T> (T x); IVL<T> hull; }; A value that contains other distinct values in no particular order. template<ANY T> type Set<T> alias SET<T> specializes ANY { BL contains(T element); BL contains(SET<T> subset); BL isEmpty; BL notEmpty; INT cardinality; SET<T> union(SET<T> otherset); SET<T> union(T element); SET<T> except(T element); SET<T> except(SET<T> otherset); SET<T> intersection(SET<T> otherset); literal ST; promotion SET<T> (T x); IVL<T> hull; }; A value that contains other distinct values in no particular order. template<ANY T> type Set<T> alias SET<T> specializes ANY { BL contains(T element); BL contains(SET<T> subset); BL isEmpty; BL notEmpty; INT cardinality; SET<T> union(SET<T> otherset); SET<T> union(T element); SET<T> except(T element); SET<T> except(SET<T> otherset); SET<T> intersection(SET<T> otherset); literal ST; promotion SET<T> (T x); IVL<T> hull; }; A value that contains other distinct values in no particular order. template<ANY T> type Set<T> alias SET<T> specializes ANY { BL contains(T element); BL contains(SET<T> subset); BL isEmpty; BL notEmpty; INT cardinality; SET<T> union(SET<T> otherset); SET<T> union(T element); SET<T> except(T element); SET<T> except(SET<T> otherset); SET<T> intersection(SET<T> otherset); literal ST; promotion SET<T> (T x); IVL<T> hull; }; A value that contains other distinct values in no particular order. template<ANY T> type Set<T> alias SET<T> specializes ANY { BL contains(T element); BL contains(SET<T> subset); BL isEmpty; BL notEmpty; INT cardinality; SET<T> union(SET<T> otherset); SET<T> union(T element); SET<T> except(T element); SET<T> except(SET<T> otherset); SET<T> intersection(SET<T> otherset); literal ST; promotion SET<T> (T x); IVL<T> hull; }; A value that contains other distinct values in no particular order. template<ANY T> type Set<T> alias SET<T> specializes ANY { BL contains(T element); BL contains(SET<T> subset); BL isEmpty; BL notEmpty; INT cardinality; SET<T> union(SET<T> otherset); SET<T> union(T element); SET<T> except(T element); SET<T> except(SET<T> otherset); SET<T> intersection(SET<T> otherset); literal ST; promotion SET<T> (T x); IVL<T> hull; }; A value that contains other distinct values in no particular order. template<ANY T> type Set<T> alias SET<T> specializes ANY { BL contains(T element); BL contains(SET<T> subset); BL isEmpty; BL notEmpty; INT cardinality; SET<T> union(SET<T> otherset); SET<T> union(T element); SET<T> except(T element); SET<T> except(SET<T> otherset); SET<T> intersection(SET<T> otherset); literal ST; promotion SET<T> (T x); IVL<T> hull; }; A value that contains other distinct values in no particular order. template<ANY T> type Set<T> alias SET<T> specializes ANY { BL contains(T element); BL contains(SET<T> subset); BL isEmpty; BL notEmpty; INT cardinality; SET<T> union(SET<T> otherset); SET<T> union(T element); SET<T> except(T element); SET<T> except(SET<T> otherset); SET<T> intersection(SET<T> otherset); literal ST; promotion SET<T> (T x); IVL<T> hull; }; A value that contains other distinct values in no particular order. template<ANY T> type Set<T> alias SET<T> specializes ANY { BL contains(T element); BL contains(SET<T> subset); BL isEmpty; BL notEmpty; INT cardinality; SET<T> union(SET<T> otherset); SET<T> union(T element); SET<T> except(T element); SET<T> except(SET<T> otherset); SET<T> intersection(SET<T> otherset); literal ST; promotion SET<T> (T x); IVL<T> hull; }; LIST (Sequence) A value that contains other discrete (but not necessarily distinct) values in a defined sequence. A sequence may contain NULL values as items. template<ANY T> type Sequence<T> alias LIST<T> specializes ANY { T head; LIST<T> tail; BL isEmpty; BL notEmpty; T item(INT index); BL contains(T item); INT length; literal ST; promotion LIST<T> (T x); }; A value that contains other discrete (but not necessarily distinct) values in a defined sequence. A sequence may contain NULL values as items. template<ANY T> type Sequence<T> alias LIST<T> specializes ANY { T head; LIST<T> tail; BL isEmpty; BL notEmpty; T item(INT index); BL contains(T item); INT length; literal ST; promotion LIST<T> (T x); }; A value that contains other discrete (but not necessarily distinct) values in a defined sequence. A sequence may contain NULL values as items. template<ANY T> type Sequence<T> alias LIST<T> specializes ANY { T head; LIST<T> tail; BL isEmpty; BL notEmpty; T item(INT index); BL contains(T item); INT length; literal ST; promotion LIST<T> (T x); }; A value that contains other discrete (but not necessarily distinct) values in a defined sequence. A sequence may contain NULL values as items. template<ANY T> type Sequence<T> alias LIST<T> specializes ANY { T head; LIST<T> tail; BL isEmpty; BL notEmpty; T item(INT index); BL contains(T item); INT length; literal ST; promotion LIST<T> (T x); }; A value that contains other discrete (but not necessarily distinct) values in a defined sequence. A sequence may contain NULL values as items. template<ANY T> type Sequence<T> alias LIST<T> specializes ANY { T head; LIST<T> tail; BL isEmpty; BL notEmpty; T item(INT index); BL contains(T item); INT length; literal ST; promotion LIST<T> (T x); }; A value that contains other discrete (but not necessarily distinct) values in a defined sequence. A sequence may contain NULL values as items. template<ANY T> type Sequence<T> alias LIST<T> specializes ANY { T head; LIST<T> tail; BL isEmpty; BL notEmpty; T item(INT index); BL contains(T item); INT length; literal ST; promotion LIST<T> (T x); }; A value that contains other discrete (but not necessarily distinct) values in a defined sequence. A sequence may contain NULL values as items. template<ANY T> type Sequence<T> alias LIST<T> specializes ANY { T head; LIST<T> tail; BL isEmpty; BL notEmpty; T item(INT index); BL contains(T item); INT length; literal ST; promotion LIST<T> (T x); }; A value that contains other discrete (but not necessarily distinct) values in a defined sequence. A sequence may contain NULL values as items. template<ANY T> type Sequence<T> alias LIST<T> specializes ANY { T head; LIST<T> tail; BL isEmpty; BL notEmpty; T item(INT index); BL contains(T item); INT length; literal ST; promotion LIST<T> (T x); }; A value that contains other discrete (but not necessarily distinct) values in a defined sequence. A sequence may contain NULL values as items. template<ANY T> type Sequence<T> alias LIST<T> specializes ANY { T head; LIST<T> tail; BL isEmpty; BL notEmpty; T item(INT index); BL contains(T item); INT length; literal ST; promotion LIST<T> (T x); }; A value that contains other discrete (but not necessarily distinct) values in a defined sequence. A sequence may contain NULL values as items. template<ANY T> type Sequence<T> alias LIST<T> specializes ANY { T head; LIST<T> tail; BL isEmpty; BL notEmpty; T item(INT index); BL contains(T item); INT length; literal ST; promotion LIST<T> (T x); }; A value that contains other discrete (but not necessarily distinct) values in a defined sequence. A sequence may contain NULL values as items. template<ANY T> type Sequence<T> alias LIST<T> specializes ANY { T head; LIST<T> tail; BL isEmpty; BL notEmpty; T item(INT index); BL contains(T item); INT length; literal ST; promotion LIST<T> (T x); }; GLIST (GeneratedSequence) A periodic or monotone sequence of values generated from a few parameters, rather than being enumerated. Used to specify regular sampling points for biosignals. The item at a certain index in the list is calculated by performing an integer division on the index (i) with the (d) and then take that value's remainder with the (p). Multiply this value with the (?x) and add to the (x 0.) x i = x 0 + ?x ? (i/d) mod p Examples for Generated Sequences head increment denominator period meaning 0 1 1 8 The identity-sequence where each item is equal to its index. 198706052000 2 hour 1 8 Sequence starting on June 5, 1987 at 7 PM and incrementing every two hours: 9 PM, 11 PM, 1 AM (June 6), 3 AM, 5 AM, and so on. 0 V 1 mV 1 100 The x-wave of a digital oscillograph scanning between 0 and 100 mV in 100 steps of 1 mV. The frequency is unknown from these data as we do not know how much time elapses between each step of the index. 2002072920300 100 us 1 8 A timebase from June 29, 2002 at 8:30 PM with 100 us between each steps of the index. If combined with the previous generator as a second sampling dimension this would now describe our digital oscilloscope's x-timebase as 1 mV per 100 us. At 100 steps per period, the period is 10 ms, which is equal to a frequency of 100 Hz. 0 V 1 mV 100 100 Combining this generator to the previous two generators could describe a three-dimensional sampling space with two voltages and time. This generator also steps at 1 mV and has 100 steps per period, however, it only steps every 100 index increments, so, the first voltage generator makes one full cycle before this generator is incremented. One can think of the two voltages as "rows" and "columns" of a "sampling frame". With the previous generator as the timebase, this results in a scan of sampling frames of 100 mV ? 100 mV with a framerate of 1 Hz. template<QTY T> type GeneratedSequence<T> alias GLIST<T> specializes LIST<T> { QTY increment; INT period; INT denominator; }; A periodic or monotone sequence of values generated from a few parameters, rather than being enumerated. Used to specify regular sampling points for biosignals. The item at a certain index in the list is calculated by performing an integer division on the index (i) with the (d) and then take that value's remainder with the (p). Multiply this value with the (?x) and add to the (x 0.) x i = x 0 + ?x ? (i/d) mod p Examples for Generated Sequences head increment denominator period meaning 0 1 1 8 The identity-sequence where each item is equal to its index. 198706052000 2 hour 1 8 Sequence starting on June 5, 1987 at 7 PM and incrementing every two hours: 9 PM, 11 PM, 1 AM (June 6), 3 AM, 5 AM, and so on. 0 V 1 mV 1 100 The x-wave of a digital oscillograph scanning between 0 and 100 mV in 100 steps of 1 mV. The frequency is unknown from these data as we do not know how much time elapses between each step of the index. 2002072920300 100 us 1 8 A timebase from June 29, 2002 at 8:30 PM with 100 us between each steps of the index. If combined with the previous generator as a second sampling dimension this would now describe our digital oscilloscope's x-timebase as 1 mV per 100 us. At 100 steps per period, the period is 10 ms, which is equal to a frequency of 100 Hz. 0 V 1 mV 100 100 Combining this generator to the previous two generators could describe a three-dimensional sampling space with two voltages and time. This generator also steps at 1 mV and has 100 steps per period, however, it only steps every 100 index increments, so, the first voltage generator makes one full cycle before this generator is incremented. One can think of the two voltages as "rows" and "columns" of a "sampling frame". With the previous generator as the timebase, this results in a scan of sampling frames of 100 mV ? 100 mV with a framerate of 1 Hz. template<QTY T> type GeneratedSequence<T> alias GLIST<T> specializes LIST<T> { QTY increment; INT period; INT denominator; }; A periodic or monotone sequence of values generated from a few parameters, rather than being enumerated. Used to specify regular sampling points for biosignals. The item at a certain index in the list is calculated by performing an integer division on the index (i) with the (d) and then take that value's remainder with the (p). Multiply this value with the (?x) and add to the (x 0.) x i = x 0 + ?x ? (i/d) mod p Examples for Generated Sequences head increment denominator period meaning 0 1 1 8 The identity-sequence where each item is equal to its index. 198706052000 2 hour 1 8 Sequence starting on June 5, 1987 at 7 PM and incrementing every two hours: 9 PM, 11 PM, 1 AM (June 6), 3 AM, 5 AM, and so on. 0 V 1 mV 1 100 The x-wave of a digital oscillograph scanning between 0 and 100 mV in 100 steps of 1 mV. The frequency is unknown from these data as we do not know how much time elapses between each step of the index. 2002072920300 100 us 1 8 A timebase from June 29, 2002 at 8:30 PM with 100 us between each steps of the index. If combined with the previous generator as a second sampling dimension this would now describe our digital oscilloscope's x-timebase as 1 mV per 100 us. At 100 steps per period, the period is 10 ms, which is equal to a frequency of 100 Hz. 0 V 1 mV 100 100 Combining this generator to the previous two generators could describe a three-dimensional sampling space with two voltages and time. This generator also steps at 1 mV and has 100 steps per period, however, it only steps every 100 index increments, so, the first voltage generator makes one full cycle before this generator is incremented. One can think of the two voltages as "rows" and "columns" of a "sampling frame". With the previous generator as the timebase, this results in a scan of sampling frames of 100 mV ? 100 mV with a framerate of 1 Hz. template<QTY T> type GeneratedSequence<T> alias GLIST<T> specializes LIST<T> { QTY increment; INT period; INT denominator; }; A periodic or monotone sequence of values generated from a few parameters, rather than being enumerated. Used to specify regular sampling points for biosignals. The item at a certain index in the list is calculated by performing an integer division on the index (i) with the (d) and then take that value's remainder with the (p). Multiply this value with the (?x) and add to the (x 0.) x i = x 0 + ?x ? (i/d) mod p Examples for Generated Sequences head increment denominator period meaning 0 1 1 8 The identity-sequence where each item is equal to its index. 198706052000 2 hour 1 8 Sequence starting on June 5, 1987 at 7 PM and incrementing every two hours: 9 PM, 11 PM, 1 AM (June 6), 3 AM, 5 AM, and so on. 0 V 1 mV 1 100 The x-wave of a digital oscillograph scanning between 0 and 100 mV in 100 steps of 1 mV. The frequency is unknown from these data as we do not know how much time elapses between each step of the index. 2002072920300 100 us 1 8 A timebase from June 29, 2002 at 8:30 PM with 100 us between each steps of the index. If combined with the previous generator as a second sampling dimension this would now describe our digital oscilloscope's x-timebase as 1 mV per 100 us. At 100 steps per period, the period is 10 ms, which is equal to a frequency of 100 Hz. 0 V 1 mV 100 100 Combining this generator to the previous two generators could describe a three-dimensional sampling space with two voltages and time. This generator also steps at 1 mV and has 100 steps per period, however, it only steps every 100 index increments, so, the first voltage generator makes one full cycle before this generator is incremented. One can think of the two voltages as "rows" and "columns" of a "sampling frame". With the previous generator as the timebase, this results in a scan of sampling frames of 100 mV ? 100 mV with a framerate of 1 Hz. template<QTY T> type GeneratedSequence<T> alias GLIST<T> specializes LIST<T> { QTY increment; INT period; INT denominator; }; A periodic or monotone sequence of values generated from a few parameters, rather than being enumerated. Used to specify regular sampling points for biosignals. The item at a certain index in the list is calculated by performing an integer division on the index (i) with the (d) and then take that value's remainder with the (p). Multiply this value with the (?x) and add to the (x 0.) x i = x 0 + ?x ? (i/d) mod p Examples for Generated Sequences head increment denominator period meaning 0 1 1 8 The identity-sequence where each item is equal to its index. 198706052000 2 hour 1 8 Sequence starting on June 5, 1987 at 7 PM and incrementing every two hours: 9 PM, 11 PM, 1 AM (June 6), 3 AM, 5 AM, and so on. 0 V 1 mV 1 100 The x-wave of a digital oscillograph scanning between 0 and 100 mV in 100 steps of 1 mV. The frequency is unknown from these data as we do not know how much time elapses between each step of the index. 2002072920300 100 us 1 8 A timebase from June 29, 2002 at 8:30 PM with 100 us between each steps of the index. If combined with the previous generator as a second sampling dimension this would now describe our digital oscilloscope's x-timebase as 1 mV per 100 us. At 100 steps per period, the period is 10 ms, which is equal to a frequency of 100 Hz. 0 V 1 mV 100 100 Combining this generator to the previous two generators could describe a three-dimensional sampling space with two voltages and time. This generator also steps at 1 mV and has 100 steps per period, however, it only steps every 100 index increments, so, the first voltage generator makes one full cycle before this generator is incremented. One can think of the two voltages as "rows" and "columns" of a "sampling frame". With the previous generator as the timebase, this results in a scan of sampling frames of 100 mV ? 100 mV with a framerate of 1 Hz. template<QTY T> type GeneratedSequence<T> alias GLIST<T> specializes LIST<T> { QTY increment; INT period; INT denominator; }; SLIST (SampledSequence) A sequence of sampled values scaled and translated from a list of integer values. Used to specify sampled biosignals. The item at a certain index (i) in the list is calculated by multiplying the item at the same index in the sequence (d i ) with the (s) and then add that value to the (x o ). x i = x o + s ? d i template<QTY T> type SampledSequence<T> alias SLIST<T> specializes LIST<T> { T origin; QTY scale; LIST<INT> digits; }; A sequence of sampled values scaled and translated from a list of integer values. Used to specify sampled biosignals. The item at a certain index (i) in the list is calculated by multiplying the item at the same index in the sequence (d i ) with the (s) and then add that value to the (x o ). x i = x o + s ? d i template<QTY T> type SampledSequence<T> alias SLIST<T> specializes LIST<T> { T origin; QTY scale; LIST<INT> digits; }; A sequence of sampled values scaled and translated from a list of integer values. Used to specify sampled biosignals. The item at a certain index (i) in the list is calculated by multiplying the item at the same index in the sequence (d i ) with the (s) and then add that value to the (x o ). x i = x o + s ? d i template<QTY T> type SampledSequence<T> alias SLIST<T> specializes LIST<T> { T origin; QTY scale; LIST<INT> digits; }; A sequence of sampled values scaled and translated from a list of integer values. Used to specify sampled biosignals. The item at a certain index (i) in the list is calculated by multiplying the item at the same index in the sequence (d i ) with the (s) and then add that value to the (x o ). x i = x o + s ? d i template<QTY T> type SampledSequence<T> alias SLIST<T> specializes LIST<T> { T origin; QTY scale; LIST<INT> digits; }; BAG (Bag) An unordered collection of values, where each value can be contained more than once in the collection. template<ANY T> type Bag<T> alias BAG<T> specializes ANY { INT contains(T kind); BL isEmpty; BL notEmpty; BAG<T> plus(BAG<T> x); BAG<T> minus(BAG<T> x); promotion BAG<T> (T x); }; An unordered collection of values, where each value can be contained more than once in the collection. template<ANY T> type Bag<T> alias BAG<T> specializes ANY { INT contains(T kind); BL isEmpty; BL notEmpty; BAG<T> plus(BAG<T> x); BAG<T> minus(BAG<T> x); promotion BAG<T> (T x); }; An unordered collection of values, where each value can be contained more than once in the collection. template<ANY T> type Bag<T> alias BAG<T> specializes ANY { INT contains(T kind); BL isEmpty; BL notEmpty; BAG<T> plus(BAG<T> x); BAG<T> minus(BAG<T> x); promotion BAG<T> (T x); }; An unordered collection of values, where each value can be contained more than once in the collection. template<ANY T> type Bag<T> alias BAG<T> specializes ANY { INT contains(T kind); BL isEmpty; BL notEmpty; BAG<T> plus(BAG<T> x); BAG<T> minus(BAG<T> x); promotion BAG<T> (T x); }; An unordered collection of values, where each value can be contained more than once in the collection. template<ANY T> type Bag<T> alias BAG<T> specializes ANY { INT contains(T kind); BL isEmpty; BL notEmpty; BAG<T> plus(BAG<T> x); BAG<T> minus(BAG<T> x); promotion BAG<T> (T x); }; An unordered collection of values, where each value can be contained more than once in the collection. template<ANY T> type Bag<T> alias BAG<T> specializes ANY { INT contains(T kind); BL isEmpty; BL notEmpty; BAG<T> plus(BAG<T> x); BAG<T> minus(BAG<T> x); promotion BAG<T> (T x); }; An unordered collection of values, where each value can be contained more than once in the collection. template<ANY T> type Bag<T> alias BAG<T> specializes ANY { INT contains(T kind); BL isEmpty; BL notEmpty; BAG<T> plus(BAG<T> x); BAG<T> minus(BAG<T> x); promotion BAG<T> (T x); }; IVL (Interval) A set of consecutive values of an ordered base data type. Any ordered type can be the basis of an interval; it does not matter whether the base type is discrete or continuous. If the base data type is only partially ordered, all elements of the interval must be elements of a totally ordered subset of the partially ordered data type. For example, physical quantities are considered ordered. However the ordering of physical quantities is only partial; a total order is only defined among comparable quantities (quantities of the same physical dimension.) While intervals between 2 and 4 meter exists, there is no interval between 2 meters and 4 seconds. Intervals are sets and have all the properties of sets. However, union and differences of intervals may not be intervals any more, since the elements of these union and difference sets might not be contiguous. Intersections of intervals are always intervals. template<QTY T> type Interval<T> alias IVL<T> specializes SET<T> { T low; BL lowClosed; T high; BL highClosed; QTY width; T center; IVL<T> hull(IVL<T> x); literal ST; promotion IVL<T> (T x); demotion T; }; A set of consecutive values of an ordered base data type. Any ordered type can be the basis of an interval; it does not matter whether the base type is discrete or continuous. If the base data type is only partially ordered, all elements of the interval must be elements of a totally ordered subset of the partially ordered data type. For example, physical quantities are considered ordered. However the ordering of physical quantities is only partial; a total order is only defined among comparable quantities (quantities of the same physical dimension.) While intervals between 2 and 4 meter exists, there is no interval between 2 meters and 4 seconds. Intervals are sets and have all the properties of sets. However, union and differences of intervals may not be intervals any more, since the elements of these union and difference sets might not be contiguous. Intersections of intervals are always intervals. template<QTY T> type Interval<T> alias IVL<T> specializes SET<T> { T low; BL lowClosed; T high; BL highClosed; QTY width; T center; IVL<T> hull(IVL<T> x); literal ST; promotion IVL<T> (T x); demotion T; }; A set of consecutive values of an ordered base data type. Any ordered type can be the basis of an interval; it does not matter whether the base type is discrete or continuous. If the base data type is only partially ordered, all elements of the interval must be elements of a totally ordered subset of the partially ordered data type. For example, physical quantities are considered ordered. However the ordering of physical quantities is only partial; a total order is only defined among comparable quantities (quantities of the same physical dimension.) While intervals between 2 and 4 meter exists, there is no interval between 2 meters and 4 seconds. Intervals are sets and have all the properties of sets. However, union and differences of intervals may not be intervals any more, since the elements of these union and difference sets might not be contiguous. Intersections of intervals are always intervals. template<QTY T> type Interval<T> alias IVL<T> specializes SET<T> { T low; BL lowClosed; T high; BL highClosed; QTY width; T center; IVL<T> hull(IVL<T> x); literal ST; promotion IVL<T> (T x); demotion T; }; A set of consecutive values of an ordered base data type. Any ordered type can be the basis of an interval; it does not matter whether the base type is discrete or continuous. If the base data type is only partially ordered, all elements of the interval must be elements of a totally ordered subset of the partially ordered data type. For example, physical quantities are considered ordered. However the ordering of physical quantities is only partial; a total order is only defined among comparable quantities (quantities of the same physical dimension.) While intervals between 2 and 4 meter exists, there is no interval between 2 meters and 4 seconds. Intervals are sets and have all the properties of sets. However, union and differences of intervals may not be intervals any more, since the elements of these union and difference sets might not be contiguous. Intersections of intervals are always intervals. template<QTY T> type Interval<T> alias IVL<T> specializes SET<T> { T low; BL lowClosed; T high; BL highClosed; QTY width; T center; IVL<T> hull(IVL<T> x); literal ST; promotion IVL<T> (T x); demotion T; }; A set of consecutive values of an ordered base data type. Any ordered type can be the basis of an interval; it does not matter whether the base type is discrete or continuous. If the base data type is only partially ordered, all elements of the interval must be elements of a totally ordered subset of the partially ordered data type. For example, physical quantities are considered ordered. However the ordering of physical quantities is only partial; a total order is only defined among comparable quantities (quantities of the same physical dimension.) While intervals between 2 and 4 meter exists, there is no interval between 2 meters and 4 seconds. Intervals are sets and have all the properties of sets. However, union and differences of intervals may not be intervals any more, since the elements of these union and difference sets might not be contiguous. Intersections of intervals are always intervals. template<QTY T> type Interval<T> alias IVL<T> specializes SET<T> { T low; BL lowClosed; T high; BL highClosed; QTY width; T center; IVL<T> hull(IVL<T> x); literal ST; promotion IVL<T> (T x); demotion T; }; A set of consecutive values of an ordered base data type. Any ordered type can be the basis of an interval; it does not matter whether the base type is discrete or continuous. If the base data type is only partially ordered, all elements of the interval must be elements of a totally ordered subset of the partially ordered data type. For example, physical quantities are considered ordered. However the ordering of physical quantities is only partial; a total order is only defined among comparable quantities (quantities of the same physical dimension.) While intervals between 2 and 4 meter exists, there is no interval between 2 meters and 4 seconds. Intervals are sets and have all the properties of sets. However, union and differences of intervals may not be intervals any more, since the elements of these union and difference sets might not be contiguous. Intersections of intervals are always intervals. template<QTY T> type Interval<T> alias IVL<T> specializes SET<T> { T low; BL lowClosed; T high; BL highClosed; QTY width; T center; IVL<T> hull(IVL<T> x); literal ST; promotion IVL<T> (T x); demotion T; }; A set of consecutive values of an ordered base data type. Any ordered type can be the basis of an interval; it does not matter whether the base type is discrete or continuous. If the base data type is only partially ordered, all elements of the interval must be elements of a totally ordered subset of the partially ordered data type. For example, physical quantities are considered ordered. However the ordering of physical quantities is only partial; a total order is only defined among comparable quantities (quantities of the same physical dimension.) While intervals between 2 and 4 meter exists, there is no interval between 2 meters and 4 seconds. Intervals are sets and have all the properties of sets. However, union and differences of intervals may not be intervals any more, since the elements of these union and difference sets might not be contiguous. Intersections of intervals are always intervals. template<QTY T> type Interval<T> alias IVL<T> specializes SET<T> { T low; BL lowClosed; T high; BL highClosed; QTY width; T center; IVL<T> hull(IVL<T> x); literal ST; promotion IVL<T> (T x); demotion T; }; A set of consecutive values of an ordered base data type. Any ordered type can be the basis of an interval; it does not matter whether the base type is discrete or continuous. If the base data type is only partially ordered, all elements of the interval must be elements of a totally ordered subset of the partially ordered data type. For example, physical quantities are considered ordered. However the ordering of physical quantities is only partial; a total order is only defined among comparable quantities (quantities of the same physical dimension.) While intervals between 2 and 4 meter exists, there is no interval between 2 meters and 4 seconds. Intervals are sets and have all the properties of sets. However, union and differences of intervals may not be intervals any more, since the elements of these union and difference sets might not be contiguous. Intersections of intervals are always intervals. template<QTY T> type Interval<T> alias IVL<T> specializes SET<T> { T low; BL lowClosed; T high; BL highClosed; QTY width; T center; IVL<T> hull(IVL<T> x); literal ST; promotion IVL<T> (T x); demotion T; }; A set of consecutive values of an ordered base data type. Any ordered type can be the basis of an interval; it does not matter whether the base type is discrete or continuous. If the base data type is only partially ordered, all elements of the interval must be elements of a totally ordered subset of the partially ordered data type. For example, physical quantities are considered ordered. However the ordering of physical quantities is only partial; a total order is only defined among comparable quantities (quantities of the same physical dimension.) While intervals between 2 and 4 meter exists, there is no interval between 2 meters and 4 seconds. Intervals are sets and have all the properties of sets. However, union and differences of intervals may not be intervals any more, since the elements of these union and difference sets might not be contiguous. Intersections of intervals are always intervals. template<QTY T> type Interval<T> alias IVL<T> specializes SET<T> { T low; BL lowClosed; T high; BL highClosed; QTY width; T center; IVL<T> hull(IVL<T> x); literal ST; promotion IVL<T> (T x); demotion T; }; A set of consecutive values of an ordered base data type. Any ordered type can be the basis of an interval; it does not matter whether the base type is discrete or continuous. If the base data type is only partially ordered, all elements of the interval must be elements of a totally ordered subset of the partially ordered data type. For example, physical quantities are considered ordered. However the ordering of physical quantities is only partial; a total order is only defined among comparable quantities (quantities of the same physical dimension.) While intervals between 2 and 4 meter exists, there is no interval between 2 meters and 4 seconds. Intervals are sets and have all the properties of sets. However, union and differences of intervals may not be intervals any more, since the elements of these union and difference sets might not be contiguous. Intersections of intervals are always intervals. template<QTY T> type Interval<T> alias IVL<T> specializes SET<T> { T low; BL lowClosed; T high; BL highClosed; QTY width; T center; IVL<T> hull(IVL<T> x); literal ST; promotion IVL<T> (T x); demotion T; }; A set of consecutive values of an ordered base data type. Any ordered type can be the basis of an interval; it does not matter whether the base type is discrete or continuous. If the base data type is only partially ordered, all elements of the interval must be elements of a totally ordered subset of the partially ordered data type. For example, physical quantities are considered ordered. However the ordering of physical quantities is only partial; a total order is only defined among comparable quantities (quantities of the same physical dimension.) While intervals between 2 and 4 meter exists, there is no interval between 2 meters and 4 seconds. Intervals are sets and have all the properties of sets. However, union and differences of intervals may not be intervals any more, since the elements of these union and difference sets might not be contiguous. Intersections of intervals are always intervals. template<QTY T> type Interval<T> alias IVL<T> specializes SET<T> { T low; BL lowClosed; T high; BL highClosed; QTY width; T center; IVL<T> hull(IVL<T> x); literal ST; promotion IVL<T> (T x); demotion T; }; A set of consecutive values of an ordered base data type. Any ordered type can be the basis of an interval; it does not matter whether the base type is discrete or continuous. If the base data type is only partially ordered, all elements of the interval must be elements of a totally ordered subset of the partially ordered data type. For example, physical quantities are considered ordered. However the ordering of physical quantities is only partial; a total order is only defined among comparable quantities (quantities of the same physical dimension.) While intervals between 2 and 4 meter exists, there is no interval between 2 meters and 4 seconds. Intervals are sets and have all the properties of sets. However, union and differences of intervals may not be intervals any more, since the elements of these union and difference sets might not be contiguous. Intersections of intervals are always intervals. template<QTY T> type Interval<T> alias IVL<T> specializes SET<T> { T low; BL lowClosed; T high; BL highClosed; QTY width; T center; IVL<T> hull(IVL<T> x); literal ST; promotion IVL<T> (T x); demotion T; }; IVL_PQ (Interval<PhysicalQuantity>) A set of consecutive values of physical quantities. An interval of physical quantities is constructed from the generic interval type. However, recognizing that the unit can be factored from the boundaries, we add additional semantics and a separate literal form. The additional view of an interval of physical quantities is an interval of real numbers with one unit. The unit applies to both low and high boundary. The special literal form is simply an interval of real numbers a space and the unit. For example: "[0;5] mmol/L" or "<20 mg/dL" are valid literal forms of intervals of physical quantities. The generic interval form, e.g., "[50 nm; 2 m]" is also allowed. type Interval<PhysicalQuantity> alias IVL<PQ> specializes IVL<T> { IVL<REAL> value; CS unit; }; A set of consecutive values of physical quantities. An interval of physical quantities is constructed from the generic interval type. However, recognizing that the unit can be factored from the boundaries, we add additional semantics and a separate literal form. The additional view of an interval of physical quantities is an interval of real numbers with one unit. The unit applies to both low and high boundary. The special literal form is simply an interval of real numbers a space and the unit. For example: "[0;5] mmol/L" or "<20 mg/dL" are valid literal forms of intervals of physical quantities. The generic interval form, e.g., "[50 nm; 2 m]" is also allowed. type Interval<PhysicalQuantity> alias IVL<PQ> specializes IVL<T> { IVL<REAL> value; CS unit; }; A set of consecutive values of physical quantities. An interval of physical quantities is constructed from the generic interval type. However, recognizing that the unit can be factored from the boundaries, we add additional semantics and a separate literal form. The additional view of an interval of physical quantities is an interval of real numbers with one unit. The unit applies to both low and high boundary. The special literal form is simply an interval of real numbers a space and the unit. For example: "[0;5] mmol/L" or "<20 mg/dL" are valid literal forms of intervals of physical quantities. The generic interval form, e.g., "[50 nm; 2 m]" is also allowed. type Interval<PhysicalQuantity> alias IVL<PQ> specializes IVL<T> { IVL<REAL> value; CS unit; }; IVL_TS (Interval<PointInTime>) A set of consecutive values of time-stamps. The generic interval data type defines the interval of points in time too. However, there are some special considerations about literal representations and conversions of intervals of point in time, which are specified in this section. type Interval<PointInTime> alias IVL<TS> specializes IVL<T> { promotion IVL<TS> (TS x); }; A set of consecutive values of time-stamps. The generic interval data type defines the interval of points in time too. However, there are some special considerations about literal representations and conversions of intervals of point in time, which are specified in this section. type Interval<PointInTime> alias IVL<TS> specializes IVL<T> { promotion IVL<TS> (TS x); }; A set of consecutive values of time-stamps. The generic interval data type defines the interval of points in time too. However, there are some special considerations about literal representations and conversions of intervals of point in time, which are specified in this section. type Interval<PointInTime> alias IVL<TS> specializes IVL<T> { promotion IVL<TS> (TS x); }; HXIT (HistoryItem) A generic data type extension that tags a time range to any data value of any data type. The time range is the time in which the information represented by the value is (was) valid. If the base type T does not possess a validTime property, the adds that property to the base type. If, however, the base type T does have a valid time property (currently only EN), that property is mapped to the valid time property of the . Note that data types are specifications of abstract properties of values. This specification does not mandate how these values are represented in an ITS or implemented in an application. Specifically, it does not mandate how the represented components are named or positioned. In addition, the semantic generalization hierarchy may be different from a class hierarchy chosen for implementation (if the implementation technology has inheritance.) Keep the distinction between a type (interface) and an implementation (concrete data structure, class) in mind. The ITS must contain a mapping of ITS defined features of any data type to the semantic properties defined here. template<ANY T> protected type HistoryItem<T> alias HXIT<T> specializes T { IVL<TS> validTime; }; A generic data type extension that tags a time range to any data value of any data type. The time range is the time in which the information represented by the value is (was) valid. If the base type T does not possess a validTime property, the adds that property to the base type. If, however, the base type T does have a valid time property (currently only EN), that property is mapped to the valid time property of the . Note that data types are specifications of abstract properties of values. This specification does not mandate how these values are represented in an ITS or implemented in an application. Specifically, it does not mandate how the represented components are named or positioned. In addition, the semantic generalization hierarchy may be different from a class hierarchy chosen for implementation (if the implementation technology has inheritance.) Keep the distinction between a type (interface) and an implementation (concrete data structure, class) in mind. The ITS must contain a mapping of ITS defined features of any data type to the semantic properties defined here. template<ANY T> protected type HistoryItem<T> alias HXIT<T> specializes T { IVL<TS> validTime; }; HIST (History) A set of data values that have a a valid-time property and thus conform to the history item (HXIT) type. The history information is not limited to the past; expected future values can also appear. The intent of the HIST data type is to capture the true historical (and future) values of an item, rather than the audit trail of values any given system has held for the item template<ANY T> type History<T> alias HIST<T> specializes SET<HXIT<T>> { HXIT<T> earliest; HIST<T> exceptEarliest; HXIT<T> latest; HIST<T> exceptLatest; demotion HXIT<T>; }; A set of data values that have a a valid-time property and thus conform to the history item (HXIT) type. The history information is not limited to the past; expected future values can also appear. The intent of the HIST data type is to capture the true historical (and future) values of an item, rather than the audit trail of values any given system has held for the item template<ANY T> type History<T> alias HIST<T> specializes SET<HXIT<T>> { HXIT<T> earliest; HIST<T> exceptEarliest; HXIT<T> latest; HIST<T> exceptLatest; demotion HXIT<T>; }; A set of data values that have a a valid-time property and thus conform to the history item (HXIT) type. The history information is not limited to the past; expected future values can also appear. The intent of the HIST data type is to capture the true historical (and future) values of an item, rather than the audit trail of values any given system has held for the item template<ANY T> type History<T> alias HIST<T> specializes SET<HXIT<T>> { HXIT<T> earliest; HIST<T> exceptEarliest; HXIT<T> latest; HIST<T> exceptLatest; demotion HXIT<T>; }; A set of data values that have a a valid-time property and thus conform to the history item (HXIT) type. The history information is not limited to the past; expected future values can also appear. The intent of the HIST data type is to capture the true historical (and future) values of an item, rather than the audit trail of values any given system has held for the item template<ANY T> type History<T> alias HIST<T> specializes SET<HXIT<T>> { HXIT<T> earliest; HIST<T> exceptEarliest; HXIT<T> latest; HIST<T> exceptLatest; demotion HXIT<T>; }; A set of data values that have a a valid-time property and thus conform to the history item (HXIT) type. The history information is not limited to the past; expected future values can also appear. The intent of the HIST data type is to capture the true historical (and future) values of an item, rather than the audit trail of values any given system has held for the item template<ANY T> type History<T> alias HIST<T> specializes SET<HXIT<T>> { HXIT<T> earliest; HIST<T> exceptEarliest; HXIT<T> latest; HIST<T> exceptLatest; demotion HXIT<T>; }; A set of data values that have a a valid-time property and thus conform to the history item (HXIT) type. The history information is not limited to the past; expected future values can also appear. The intent of the HIST data type is to capture the true historical (and future) values of an item, rather than the audit trail of values any given system has held for the item template<ANY T> type History<T> alias HIST<T> specializes SET<HXIT<T>> { HXIT<T> earliest; HIST<T> exceptEarliest; HXIT<T> latest; HIST<T> exceptLatest; demotion HXIT<T>; }; UVP (UncertainValueProbabilistic) A generic data type extension used to specify a probability expressing the information producer's belief that the given value holds. How the probability number was arrived at is outside the scope of this specification. Probabilities are subjective and (as any data value) must be interpreted in their individual context, for example, when new information is found the probability might change. Thus, for any message (document, or other information representation) the information - and particularly the probabilities - reflect what the information producer believed was appropriate for the purpose and at the time the message (document) was created. For example, at the beginning of the 2000 baseball season (May), the Las Vegas odds makers may have given the New York Yankees a probability of 1 in 10 (0.100) of winning the World Series. At the time of this writing, the Yankees and Mets have won their respective pennants, but the World Series has yet to begin. The probability of the Yankees winning the World Series is obviously significantly greater at this point in time, perhaps 6 in 10 (0.600). The context, and in particular the time of year, made all the difference in the world. Since probabilities are subjective measures of belief, they can be stated without being "correct" or "incorrect" per se, let alone "precise" or "imprecise". Notably, one does not have to conduct experiments to measure a frequency of some outcome in order to specify a probability. In fact, whenever statements about individual people or events are made, it is not possible to confirm such probabilities with "frequentists" experiments. Returning to our example, the Las Vegas odds makers can not insist on the Yankees and Mets playing 1000 trial games prior to the Series; even if they could, they would not have the fervor of the real Series and therefore not be accurate. Instead, the odds makers must derive the probability from past history, player statistics, injuries, etc. The type T is not formally constrained. In theory, discrete probabilities can only be stated for discrete data values. Thus, generally should not be used with , , or values. template<ANY T> type UncertainValueProbabilistic<T> alias UVP<T> specializes T { REAL probability; }; A generic data type extension used to specify a probability expressing the information producer's belief that the given value holds. How the probability number was arrived at is outside the scope of this specification. Probabilities are subjective and (as any data value) must be interpreted in their individual context, for example, when new information is found the probability might change. Thus, for any message (document, or other information representation) the information - and particularly the probabilities - reflect what the information producer believed was appropriate for the purpose and at the time the message (document) was created. For example, at the beginning of the 2000 baseball season (May), the Las Vegas odds makers may have given the New York Yankees a probability of 1 in 10 (0.100) of winning the World Series. At the time of this writing, the Yankees and Mets have won their respective pennants, but the World Series has yet to begin. The probability of the Yankees winning the World Series is obviously significantly greater at this point in time, perhaps 6 in 10 (0.600). The context, and in particular the time of year, made all the difference in the world. Since probabilities are subjective measures of belief, they can be stated without being "correct" or "incorrect" per se, let alone "precise" or "imprecise". Notably, one does not have to conduct experiments to measure a frequency of some outcome in order to specify a probability. In fact, whenever statements about individual people or events are made, it is not possible to confirm such probabilities with "frequentists" experiments. Returning to our example, the Las Vegas odds makers can not insist on the Yankees and Mets playing 1000 trial games prior to the Series; even if they could, they would not have the fervor of the real Series and therefore not be accurate. Instead, the odds makers must derive the probability from past history, player statistics, injuries, etc. The type T is not formally constrained. In theory, discrete probabilities can only be stated for discrete data values. Thus, generally should not be used with , , or values. template<ANY T> type UncertainValueProbabilistic<T> alias UVP<T> specializes T { REAL probability; }; NPPD (NonParametricProbabilityDistribution) A set of uncertain values with probabilities (also known as histogram.) All the elements in the set are considered alternatives and are rated each with its probability expressing the belief (or frequency) that each given value holds. The purpose of the non-parametric probability distribution is chiefly to support statistical data reporting as it occurs in measurements taken from many subjects and consolidated in a histogram. This occurs in epidemiology, veterinary medicine, laboratory medicine, but also in cost controlling and business process engineering. Semantically, the information of a stated value exists in contrast to the complement set of unstated possible values. Thus, semantically, a non-parametric probability distribution contains all possible values and assigns probabilities to each of them. The easiest way to visualize this is a bar chart as shown in This example illustrates the probability of selected major league baseball teams winning the World Series (prior to the season start). Each team is mutually exclusive, and were we to include all of the teams, the sum of the probabilities would equal 1 (i.e., it is certain that one of the teams will win). Just as with , the type T is not formally constrained, even though there are reasonable and unreasonable uses. Typically one would use the for unordered types, if only a "small" set of possible values is assigned explicit probabilities, or if the probability distribution cannot (or should not) be approximated with parametric methods. For other cases, one may prefer . template<ANY T> type NonParametricProbabilityDistribution<T> alias NPPD<T> specializes SET<UVP<T>> { UVP<T> mostLikely(INT n); }; A set of uncertain values with probabilities (also known as histogram.) All the elements in the set are considered alternatives and are rated each with its probability expressing the belief (or frequency) that each given value holds. The purpose of the non-parametric probability distribution is chiefly to support statistical data reporting as it occurs in measurements taken from many subjects and consolidated in a histogram. This occurs in epidemiology, veterinary medicine, laboratory medicine, but also in cost controlling and business process engineering. Semantically, the information of a stated value exists in contrast to the complement set of unstated possible values. Thus, semantically, a non-parametric probability distribution contains all possible values and assigns probabilities to each of them. The easiest way to visualize this is a bar chart as shown in This example illustrates the probability of selected major league baseball teams winning the World Series (prior to the season start). Each team is mutually exclusive, and were we to include all of the teams, the sum of the probabilities would equal 1 (i.e., it is certain that one of the teams will win). Just as with , the type T is not formally constrained, even though there are reasonable and unreasonable uses. Typically one would use the for unordered types, if only a "small" set of possible values is assigned explicit probabilities, or if the probability distribution cannot (or should not) be approximated with parametric methods. For other cases, one may prefer . template<ANY T> type NonParametricProbabilityDistribution<T> alias NPPD<T> specializes SET<UVP<T>> { UVP<T> mostLikely(INT n); }; PIVL (PeriodicIntervalOfTime) An interval of time that recurs periodically. Periodic intervals have two properties, phase and period. The phase specifies the "interval prototype" that is repeated every period. For example, "every eight hours for two minutes" is a periodic interval where the interval's width equals 2 minutes and the period at which the interval recurs equals 8 hours. The phase also marks the anchor point in time for the entire series of periodically recurring intervals. The recurrence of a periodic interval has no beginning or ending, but is infinite in both future and past. A periodic interval is fully specified when both the period and the phase are fully specified. The interval may be only partially specified where either only the width or only one boundary is specified. For example: "every eight hours for two minutes" specifies only the period and the phase's width but no boundary of the phase. Conversely, "every eight hours starting at 4 o'clock" specifies only the period and the phase's low boundary but not the phase's high boundary. "Every eight hours for two minutes starting at 4 o'clock" is fully specified since the period, and both the phase's low boundary and width are specified (low boundary and width implies the high boundary.) The periodic interval of time is a generic type extension whose type parameter T is restricted to the point in time ( ) data type and its extensions. The parametric probability distribution of point in time ( < >) is an extension of point in time and therefore can be used to form periodic intervals of probability distributions of point in time ( < < >>) values (uncertain periodic interval.) Oftentimes repeating schedules are only approximately specified. For instance "three times a day for ten minutes each" does not usually mean a period of precisely 8 hours and does often not mean exactly 10 minutes intervals. Rather the distance between each occurrence may vary as much as between 3 and 12 hours and the width of the interval may be less than 5 minutes or more than 15 minutes. An uncertain periodic interval can be used to indicate how much leeway is allowed or how "timing-critical" the specification is. The essential property of a set is that it contains elements. For non-aligned periodic intervals, the contains-property is defined as follows. A point in time t is contained in the periodic interval of time if and only if there is an integer i for which t plus the period times i is an element of the phase interval. invariant (PIVL<TS> x, TS t) where x.nonNull.and(x.alignment.isNull) { x.contains(t).equal(exists(INT i) { x.phase.contains(t.plus(x.period.times(i))); }); }; For calendar-aligned periodic intervals the contains property is defined using the calendar-cycle's sum(t, n) property that adds n such calendar cycles to the time t. invariant (PIVL<TS> x, TS t, CalendarCycle c) where x.nonNull.and(c.equal(x.alignment)) { x.contains(t).equal(exists(INT i) { x.phase.contains(c.sum(t, i)); }); }; template<TS T> type PeriodicIntervalOfTime<T> alias PIVL<T> specializes SET<T> { IVL<T> phase; PQ period; CS alignment; BL institutionSpecifiedTime; literal ST; }; An interval of time that recurs periodically. Periodic intervals have two properties, phase and period. The phase specifies the "interval prototype" that is repeated every period. For example, "every eight hours for two minutes" is a periodic interval where the interval's width equals 2 minutes and the period at which the interval recurs equals 8 hours. The phase also marks the anchor point in time for the entire series of periodically recurring intervals. The recurrence of a periodic interval has no beginning or ending, but is infinite in both future and past. A periodic interval is fully specified when both the period and the phase are fully specified. The interval may be only partially specified where either only the width or only one boundary is specified. For example: "every eight hours for two minutes" specifies only the period and the phase's width but no boundary of the phase. Conversely, "every eight hours starting at 4 o'clock" specifies only the period and the phase's low boundary but not the phase's high boundary. "Every eight hours for two minutes starting at 4 o'clock" is fully specified since the period, and both the phase's low boundary and width are specified (low boundary and width implies the high boundary.) The periodic interval of time is a generic type extension whose type parameter T is restricted to the point in time ( ) data type and its extensions. The parametric probability distribution of point in time ( < >) is an extension of point in time and therefore can be used to form periodic intervals of probability distributions of point in time ( < < >>) values (uncertain periodic interval.) Oftentimes repeating schedules are only approximately specified. For instance "three times a day for ten minutes each" does not usually mean a period of precisely 8 hours and does often not mean exactly 10 minutes intervals. Rather the distance between each occurrence may vary as much as between 3 and 12 hours and the width of the interval may be less than 5 minutes or more than 15 minutes. An uncertain periodic interval can be used to indicate how much leeway is allowed or how "timing-critical" the specification is. The essential property of a set is that it contains elements. For non-aligned periodic intervals, the contains-property is defined as follows. A point in time t is contained in the periodic interval of time if and only if there is an integer i for which t plus the period times i is an element of the phase interval. invariant (PIVL<TS> x, TS t) where x.nonNull.and(x.alignment.isNull) { x.contains(t).equal(exists(INT i) { x.phase.contains(t.plus(x.period.times(i))); }); }; For calendar-aligned periodic intervals the contains property is defined using the calendar-cycle's sum(t, n) property that adds n such calendar cycles to the time t. invariant (PIVL<TS> x, TS t, CalendarCycle c) where x.nonNull.and(c.equal(x.alignment)) { x.contains(t).equal(exists(INT i) { x.phase.contains(c.sum(t, i)); }); }; template<TS T> type PeriodicIntervalOfTime<T> alias PIVL<T> specializes SET<T> { IVL<T> phase; PQ period; CS alignment; BL institutionSpecifiedTime; literal ST; }; An interval of time that recurs periodically. Periodic intervals have two properties, phase and period. The phase specifies the "interval prototype" that is repeated every period. For example, "every eight hours for two minutes" is a periodic interval where the interval's width equals 2 minutes and the period at which the interval recurs equals 8 hours. The phase also marks the anchor point in time for the entire series of periodically recurring intervals. The recurrence of a periodic interval has no beginning or ending, but is infinite in both future and past. A periodic interval is fully specified when both the period and the phase are fully specified. The interval may be only partially specified where either only the width or only one boundary is specified. For example: "every eight hours for two minutes" specifies only the period and the phase's width but no boundary of the phase. Conversely, "every eight hours starting at 4 o'clock" specifies only the period and the phase's low boundary but not the phase's high boundary. "Every eight hours for two minutes starting at 4 o'clock" is fully specified since the period, and both the phase's low boundary and width are specified (low boundary and width implies the high boundary.) The periodic interval of time is a generic type extension whose type parameter T is restricted to the point in time ( ) data type and its extensions. The parametric probability distribution of point in time ( < >) is an extension of point in time and therefore can be used to form periodic intervals of probability distributions of point in time ( < < >>) values (uncertain periodic interval.) Oftentimes repeating schedules are only approximately specified. For instance "three times a day for ten minutes each" does not usually mean a period of precisely 8 hours and does often not mean exactly 10 minutes intervals. Rather the distance between each occurrence may vary as much as between 3 and 12 hours and the width of the interval may be less than 5 minutes or more than 15 minutes. An uncertain periodic interval can be used to indicate how much leeway is allowed or how "timing-critical" the specification is. The essential property of a set is that it contains elements. For non-aligned periodic intervals, the contains-property is defined as follows. A point in time t is contained in the periodic interval of time if and only if there is an integer i for which t plus the period times i is an element of the phase interval. invariant (PIVL<TS> x, TS t) where x.nonNull.and(x.alignment.isNull) { x.contains(t).equal(exists(INT i) { x.phase.contains(t.plus(x.period.times(i))); }); }; For calendar-aligned periodic intervals the contains property is defined using the calendar-cycle's sum(t, n) property that adds n such calendar cycles to the time t. invariant (PIVL<TS> x, TS t, CalendarCycle c) where x.nonNull.and(c.equal(x.alignment)) { x.contains(t).equal(exists(INT i) { x.phase.contains(c.sum(t, i)); }); }; template<TS T> type PeriodicIntervalOfTime<T> alias PIVL<T> specializes SET<T> { IVL<T> phase; PQ period; CS alignment; BL institutionSpecifiedTime; literal ST; }; An interval of time that recurs periodically. Periodic intervals have two properties, phase and period. The phase specifies the "interval prototype" that is repeated every period. For example, "every eight hours for two minutes" is a periodic interval where the interval's width equals 2 minutes and the period at which the interval recurs equals 8 hours. The phase also marks the anchor point in time for the entire series of periodically recurring intervals. The recurrence of a periodic interval has no beginning or ending, but is infinite in both future and past. A periodic interval is fully specified when both the period and the phase are fully specified. The interval may be only partially specified where either only the width or only one boundary is specified. For example: "every eight hours for two minutes" specifies only the period and the phase's width but no boundary of the phase. Conversely, "every eight hours starting at 4 o'clock" specifies only the period and the phase's low boundary but not the phase's high boundary. "Every eight hours for two minutes starting at 4 o'clock" is fully specified since the period, and both the phase's low boundary and width are specified (low boundary and width implies the high boundary.) The periodic interval of time is a generic type extension whose type parameter T is restricted to the point in time ( ) data type and its extensions. The parametric probability distribution of point in time ( < >) is an extension of point in time and therefore can be used to form periodic intervals of probability distributions of point in time ( < < >>) values (uncertain periodic interval.) Oftentimes repeating schedules are only approximately specified. For instance "three times a day for ten minutes each" does not usually mean a period of precisely 8 hours and does often not mean exactly 10 minutes intervals. Rather the distance between each occurrence may vary as much as between 3 and 12 hours and the width of the interval may be less than 5 minutes or more than 15 minutes. An uncertain periodic interval can be used to indicate how much leeway is allowed or how "timing-critical" the specification is. The essential property of a set is that it contains elements. For non-aligned periodic intervals, the contains-property is defined as follows. A point in time t is contained in the periodic interval of time if and only if there is an integer i for which t plus the period times i is an element of the phase interval. invariant (PIVL<TS> x, TS t) where x.nonNull.and(x.alignment.isNull) { x.contains(t).equal(exists(INT i) { x.phase.contains(t.plus(x.period.times(i))); }); }; For calendar-aligned periodic intervals the contains property is defined using the calendar-cycle's sum(t, n) property that adds n such calendar cycles to the time t. invariant (PIVL<TS> x, TS t, CalendarCycle c) where x.nonNull.and(c.equal(x.alignment)) { x.contains(t).equal(exists(INT i) { x.phase.contains(c.sum(t, i)); }); }; template<TS T> type PeriodicIntervalOfTime<T> alias PIVL<T> specializes SET<T> { IVL<T> phase; PQ period; CS alignment; BL institutionSpecifiedTime; literal ST; }; An interval of time that recurs periodically. Periodic intervals have two properties, phase and period. The phase specifies the "interval prototype" that is repeated every period. For example, "every eight hours for two minutes" is a periodic interval where the interval's width equals 2 minutes and the period at which the interval recurs equals 8 hours. The phase also marks the anchor point in time for the entire series of periodically recurring intervals. The recurrence of a periodic interval has no beginning or ending, but is infinite in both future and past. A periodic interval is fully specified when both the period and the phase are fully specified. The interval may be only partially specified where either only the width or only one boundary is specified. For example: "every eight hours for two minutes" specifies only the period and the phase's width but no boundary of the phase. Conversely, "every eight hours starting at 4 o'clock" specifies only the period and the phase's low boundary but not the phase's high boundary. "Every eight hours for two minutes starting at 4 o'clock" is fully specified since the period, and both the phase's low boundary and width are specified (low boundary and width implies the high boundary.) The periodic interval of time is a generic type extension whose type parameter T is restricted to the point in time ( ) data type and its extensions. The parametric probability distribution of point in time ( < >) is an extension of point in time and therefore can be used to form periodic intervals of probability distributions of point in time ( < < >>) values (uncertain periodic interval.) Oftentimes repeating schedules are only approximately specified. For instance "three times a day for ten minutes each" does not usually mean a period of precisely 8 hours and does often not mean exactly 10 minutes intervals. Rather the distance between each occurrence may vary as much as between 3 and 12 hours and the width of the interval may be less than 5 minutes or more than 15 minutes. An uncertain periodic interval can be used to indicate how much leeway is allowed or how "timing-critical" the specification is. The essential property of a set is that it contains elements. For non-aligned periodic intervals, the contains-property is defined as follows. A point in time t is contained in the periodic interval of time if and only if there is an integer i for which t plus the period times i is an element of the phase interval. invariant (PIVL<TS> x, TS t) where x.nonNull.and(x.alignment.isNull) { x.contains(t).equal(exists(INT i) { x.phase.contains(t.plus(x.period.times(i))); }); }; For calendar-aligned periodic intervals the contains property is defined using the calendar-cycle's sum(t, n) property that adds n such calendar cycles to the time t. invariant (PIVL<TS> x, TS t, CalendarCycle c) where x.nonNull.and(c.equal(x.alignment)) { x.contains(t).equal(exists(INT i) { x.phase.contains(c.sum(t, i)); }); }; template<TS T> type PeriodicIntervalOfTime<T> alias PIVL<T> specializes SET<T> { IVL<T> phase; PQ period; CS alignment; BL institutionSpecifiedTime; literal ST; }; An interval of time that recurs periodically. Periodic intervals have two properties, phase and period. The phase specifies the "interval prototype" that is repeated every period. For example, "every eight hours for two minutes" is a periodic interval where the interval's width equals 2 minutes and the period at which the interval recurs equals 8 hours. The phase also marks the anchor point in time for the entire series of periodically recurring intervals. The recurrence of a periodic interval has no beginning or ending, but is infinite in both future and past. A periodic interval is fully specified when both the period and the phase are fully specified. The interval may be only partially specified where either only the width or only one boundary is specified. For example: "every eight hours for two minutes" specifies only the period and the phase's width but no boundary of the phase. Conversely, "every eight hours starting at 4 o'clock" specifies only the period and the phase's low boundary but not the phase's high boundary. "Every eight hours for two minutes starting at 4 o'clock" is fully specified since the period, and both the phase's low boundary and width are specified (low boundary and width implies the high boundary.) The periodic interval of time is a generic type extension whose type parameter T is restricted to the point in time ( ) data type and its extensions. The parametric probability distribution of point in time ( < >) is an extension of point in time and therefore can be used to form periodic intervals of probability distributions of point in time ( < < >>) values (uncertain periodic interval.) Oftentimes repeating schedules are only approximately specified. For instance "three times a day for ten minutes each" does not usually mean a period of precisely 8 hours and does often not mean exactly 10 minutes intervals. Rather the distance between each occurrence may vary as much as between 3 and 12 hours and the width of the interval may be less than 5 minutes or more than 15 minutes. An uncertain periodic interval can be used to indicate how much leeway is allowed or how "timing-critical" the specification is. The essential property of a set is that it contains elements. For non-aligned periodic intervals, the contains-property is defined as follows. A point in time t is contained in the periodic interval of time if and only if there is an integer i for which t plus the period times i is an element of the phase interval. invariant (PIVL<TS> x, TS t) where x.nonNull.and(x.alignment.isNull) { x.contains(t).equal(exists(INT i) { x.phase.contains(t.plus(x.period.times(i))); }); }; For calendar-aligned periodic intervals the contains property is defined using the calendar-cycle's sum(t, n) property that adds n such calendar cycles to the time t. invariant (PIVL<TS> x, TS t, CalendarCycle c) where x.nonNull.and(c.equal(x.alignment)) { x.contains(t).equal(exists(INT i) { x.phase.contains(c.sum(t, i)); }); }; template<TS T> type PeriodicIntervalOfTime<T> alias PIVL<T> specializes SET<T> { IVL<T> phase; PQ period; CS alignment; BL institutionSpecifiedTime; literal ST; }; EIVL (EventRelatedPeriodicInterval) Specifies a periodic interval of time where the recurrence is based on activities of daily living or other important events that are time-related but not fully determined by time. For example, "one hour after breakfast" specifies the beginning of the interval at one hour after breakfast is finished. Breakfast is assumed to occur before lunch but is not determined to occur at any specific time. An event-related periodic interval of time is a set of time, that is, one can test whether a particular time or time interval is an element of the set. Whether an event-related periodic interval of time contains a given interval of time is decided using a relation event ? time referred to as EVENT(event, time). The property occurrenceAt(t) is the occurrence interval that would exist if the event occurred at time t. invariant(EIVL<T> x, T eventTime, IVL<T> v) where v.equal(x.occurrenceAt(eventTime)) { v.low.equal(eventTime.plus(x.offset.low)); v.high.equal(eventTime.plus(x.offset.high)); v.lowClosed.equal(x.offset.lowClosed); v.highClosed.equal(x.offset.highClosed); }; Thus, an event related interval of time contains a point in time t if there is an event time e with an occurrence interval v such that v contains t. invariant(EIVL<T> x, T y) { x.contains(y).equal(exists(T e, IVL<T> v) where EVENT(x.event, y) .and(v.resolvedAt(y)) { v.contains(y); }); }; template<TS T> type EventRelatedPeriodicInterval<T> alias EIVL<T> specializes SET<T> { CS event; IVL<PQ> offset; IVL<T> occurrenceAt(TS eventTime); literal ST; }; Specifies a periodic interval of time where the recurrence is based on activities of daily living or other important events that are time-related but not fully determined by time. For example, "one hour after breakfast" specifies the beginning of the interval at one hour after breakfast is finished. Breakfast is assumed to occur before lunch but is not determined to occur at any specific time. An event-related periodic interval of time is a set of time, that is, one can test whether a particular time or time interval is an element of the set. Whether an event-related periodic interval of time contains a given interval of time is decided using a relation event ? time referred to as EVENT(event, time). The property occurrenceAt(t) is the occurrence interval that would exist if the event occurred at time t. invariant(EIVL<T> x, T eventTime, IVL<T> v) where v.equal(x.occurrenceAt(eventTime)) { v.low.equal(eventTime.plus(x.offset.low)); v.high.equal(eventTime.plus(x.offset.high)); v.lowClosed.equal(x.offset.lowClosed); v.highClosed.equal(x.offset.highClosed); }; Thus, an event related interval of time contains a point in time t if there is an event time e with an occurrence interval v such that v contains t. invariant(EIVL<T> x, T y) { x.contains(y).equal(exists(T e, IVL<T> v) where EVENT(x.event, y) .and(v.resolvedAt(y)) { v.contains(y); }); }; template<TS T> type EventRelatedPeriodicInterval<T> alias EIVL<T> specializes SET<T> { CS event; IVL<PQ> offset; IVL<T> occurrenceAt(TS eventTime); literal ST; }; Specifies a periodic interval of time where the recurrence is based on activities of daily living or other important events that are time-related but not fully determined by time. For example, "one hour after breakfast" specifies the beginning of the interval at one hour after breakfast is finished. Breakfast is assumed to occur before lunch but is not determined to occur at any specific time. An event-related periodic interval of time is a set of time, that is, one can test whether a particular time or time interval is an element of the set. Whether an event-related periodic interval of time contains a given interval of time is decided using a relation event ? time referred to as EVENT(event, time). The property occurrenceAt(t) is the occurrence interval that would exist if the event occurred at time t. invariant(EIVL<T> x, T eventTime, IVL<T> v) where v.equal(x.occurrenceAt(eventTime)) { v.low.equal(eventTime.plus(x.offset.low)); v.high.equal(eventTime.plus(x.offset.high)); v.lowClosed.equal(x.offset.lowClosed); v.highClosed.equal(x.offset.highClosed); }; Thus, an event related interval of time contains a point in time t if there is an event time e with an occurrence interval v such that v contains t. invariant(EIVL<T> x, T y) { x.contains(y).equal(exists(T e, IVL<T> v) where EVENT(x.event, y) .and(v.resolvedAt(y)) { v.contains(y); }); }; template<TS T> type EventRelatedPeriodicInterval<T> alias EIVL<T> specializes SET<T> { CS event; IVL<PQ> offset; IVL<T> occurrenceAt(TS eventTime); literal ST; }; Specifies a periodic interval of time where the recurrence is based on activities of daily living or other important events that are time-related but not fully determined by time. For example, "one hour after breakfast" specifies the beginning of the interval at one hour after breakfast is finished. Breakfast is assumed to occur before lunch but is not determined to occur at any specific time. An event-related periodic interval of time is a set of time, that is, one can test whether a particular time or time interval is an element of the set. Whether an event-related periodic interval of time contains a given interval of time is decided using a relation event ? time referred to as EVENT(event, time). The property occurrenceAt(t) is the occurrence interval that would exist if the event occurred at time t. invariant(EIVL<T> x, T eventTime, IVL<T> v) where v.equal(x.occurrenceAt(eventTime)) { v.low.equal(eventTime.plus(x.offset.low)); v.high.equal(eventTime.plus(x.offset.high)); v.lowClosed.equal(x.offset.lowClosed); v.highClosed.equal(x.offset.highClosed); }; Thus, an event related interval of time contains a point in time t if there is an event time e with an occurrence interval v such that v contains t. invariant(EIVL<T> x, T y) { x.contains(y).equal(exists(T e, IVL<T> v) where EVENT(x.event, y) .and(v.resolvedAt(y)) { v.contains(y); }); }; template<TS T> type EventRelatedPeriodicInterval<T> alias EIVL<T> specializes SET<T> { CS event; IVL<PQ> offset; IVL<T> occurrenceAt(TS eventTime); literal ST; }; Specifies a periodic interval of time where the recurrence is based on activities of daily living or other important events that are time-related but not fully determined by time. For example, "one hour after breakfast" specifies the beginning of the interval at one hour after breakfast is finished. Breakfast is assumed to occur before lunch but is not determined to occur at any specific time. An event-related periodic interval of time is a set of time, that is, one can test whether a particular time or time interval is an element of the set. Whether an event-related periodic interval of time contains a given interval of time is decided using a relation event ? time referred to as EVENT(event, time). The property occurrenceAt(t) is the occurrence interval that would exist if the event occurred at time t. invariant(EIVL<T> x, T eventTime, IVL<T> v) where v.equal(x.occurrenceAt(eventTime)) { v.low.equal(eventTime.plus(x.offset.low)); v.high.equal(eventTime.plus(x.offset.high)); v.lowClosed.equal(x.offset.lowClosed); v.highClosed.equal(x.offset.highClosed); }; Thus, an event related interval of time contains a point in time t if there is an event time e with an occurrence interval v such that v contains t. invariant(EIVL<T> x, T y) { x.contains(y).equal(exists(T e, IVL<T> v) where EVENT(x.event, y) .and(v.resolvedAt(y)) { v.contains(y); }); }; template<TS T> type EventRelatedPeriodicInterval<T> alias EIVL<T> specializes SET<T> { CS event; IVL<PQ> offset; IVL<T> occurrenceAt(TS eventTime); literal ST; }; GTS (GeneralTimingSpecification) A set of points in time, specifying the timing of events and actions and the cyclical validity-patterns that may exist for certain kinds of information, such as phone numbers (evening, daytime), addresses (so called "snowbirds," residing closer to the equator during winter and farther from the equator during summer) and office hours. The GTS data type has the following aspects: GTS as a general set of points in time ( < >). From this aspect GTS answers whether any given point in time falls in the schedule described by the GTS value. GTS as the combination of multiple periodic intervals of time. This aspect describes how both simple and complex repeat-patterns are specified with the GTS. GTS as a generator of a sequence of intervals of point in time ( < < >>). From this aspect, GTS can generate all occurrence intervals of an event or action, or all validity periods for a fact. GTS as an expression-syntax defined for a calendar. This aspect is the GTS literal form. In all cases the GTS is defined as a set of point in time ( < >). Using the set operations, union, intersection and difference, more complex sets of time can be constructed from simpler ones. Ultimately the building blocks from which all GTS values are constructed are interval, periodic interval, and event-related periodic interval. The construction of the GTS can be specified in the literal form. No special data type structure is defined that would generate a combination of simpler time-sets from a given GTS value. While any implementation would have to contain such a structured representation, it is not needed in order to exchange GTS values given the literal form. The GTS is an example of a data type that is only defined algebraically without giving any definition of a data structure that might implement the behavior of such a data type. The algebraic definition looks extremely simple, so that one might assume it is incomplete. Since at this point we are relying entirely on the literal form to represent GTS values, all the definition of data structur The GTS data type is defined as using intervals, periodic intervals, and event-related periodic intervals. Intervals of time have been defined above A convex hull is the least interval that is a superset of all occurrence intervals. As noted in , all totally ordered sets have a convex hull. Because a GTS is a <> and because a <> is a totally ordered set, all GTS values have a convex hull. The convex hull of a GTS can less formally be called "outer bound interval". Thus, the convex hull of a GTS describes the absolute beginning and end of the repeating schedule. For infinite repetitions (e.g., a simple periodic interval) the convex hull has infinite bounds. Convex Hull of a Schedule A value is a generator of a sequence of time intervals during which an event or activity occurs, or during which a state is effective. The nextTo-property maps to every point in time t the greatest continuous subset (an "occurrence interval") v of the value S, where v is the interval closest to t that begins later than t or that contains t. invariant(GTS S, TS t, IVL<TS> v) { v.equal(S.nextTo(t)).equal( S.contains(o) .and(forall(IVL<TS> u) where x.contains(u) { u.contains(v).implies(u.equal(v)); }) .and( v.contains(t) .or(forall(TS i) where t.lessOrEqual(i) .and(i.lessThan(v.low)) { S.conatins(i).not; }))); }; The nextAfter-property maps to every point in time t the greatest continuous subset (an "occurrence interval") v of the value S, where v is the interval closest to t that begins later than t. invariant(GTS S, TS t) where { S.contains(t).not .implies(S.nextAfter(t).equal(S.nextTo(t))); S.contains(t) .implies(S.nextAfter(t).equal( S.except(nextTo(t)).nextTo(t))); }; A value can be converted into a generic Sequence of time intervals (<>) of occurrence intervals. invariant(GTS x) where x.isEmpty { ((LIST<IVL<TS>>)x).isEmpty; }; invariant(GTS x, IVL<TS> first) where x.notEmpty .and(x.hull.low.nonNull) .and(first.equal(x.nextTo(x.hull.low)) { ((LIST<IVL<TS>>)x).head.equal(first); ((LIST<IVL<TS>>)x).tail.equal( (LIST<IVL<TS>>)x.except(first)); }; Interleaving Schedules and Periodic Hull For two values A and B we say that A interleaves B if their occurrence intervals interleave on the time line. This concept is visualized in Figure 15. For the values A and B to interleave the occurrence intervals of both groups can be arranged in pairs of corresponding occurrence intervals. It must further hold that for all corresponding occurrence intervals a ? A and b ? B, a starts before b starts (or at the same time) and b ends after a ends (or at the same time). The interleaves-relation holds when two schedules have the same average frequency, and when the second schedule never "outpaces" the first schedule. That is, no occurrence interval in the second schedule may start before its corresponding occurrence interval in the first schedule. With two interleaving values one can derive a periodic hull such that the occurrence intervals of the periodic hull is the convex hull of the corresponding occurrence intervals. The periodic hull is important to construct two schedules by combining expressions. For example, to construct the periodic interval from Memorial Day to Labor Day every year, one first needs to set up the schedules M for Memorial Day (the last Monday in May) and L for Labor Day (the first Monday in September) and then combine these two schedules using the periodic hull of M and L. invariant(GTS A, B) where x.nonNull.and(y.nonNull) { A.interleaves(B).equal( forall(IVL<TS> a, b, c; TS t) where a.equal(A.nextTo(t)) .and(b.equal(B.nextTo(a.low))) .and(c.equal(A.nextTo(b.high))) { b.equal(B.nextTo(a.high)); a.low.lessOrEqual(b.low); c.equal(A.nextTo(b.high)); c.equal(a).or(c.equal(A.nextAfter(a.high))); }); }; For two values A and B where A interleaves B, a periodic hull is defined as the pair wise convex hull of the corresponding occurrence intervals of A and B. invariant(GTS A, B, C) where A.interleaves(B) { A.periodicHull(B).equal(C).equal( forall(IVL<TS> a, b; TS t) where a.equal(A.nextTo(t)) .and(b.equal(B.nextTo(a.low))) { C.contains(c).equal(c.equal(a.hull(b))); }); }; The interleaves-relation is reflexive, asymmetric, and intransitive. The periodic hull operation is non-commutative and non-associative. The interleaves property may appear overly constrained. However, these constraints are reasonable for the use case for which the interleaves and periodic hull properties are defined. To safely and predictably combine two schedules one would want to know which of the operands sets the start points and which sets the endpoints of the periodic hull's occurrence intervals. type GeneralTimingSpecification alias GTS specializes SET<TS> { IVL<TS> hull; IVL<TS> nextTo(TS x); IVL<TS> nextAfter(TS x); GTS periodicHull(GTS x); BL interleaves(GTS x); demotion LIST<IVL<TS>>; literal ST; }; A set of points in time, specifying the timing of events and actions and the cyclical validity-patterns that may exist for certain kinds of information, such as phone numbers (evening, daytime), addresses (so called "snowbirds," residing closer to the equator during winter and farther from the equator during summer) and office hours. The GTS data type has the following aspects: GTS as a general set of points in time ( < >). From this aspect GTS answers whether any given point in time falls in the schedule described by the GTS value. GTS as the combination of multiple periodic intervals of time. This aspect describes how both simple and complex repeat-patterns are specified with the GTS. GTS as a generator of a sequence of intervals of point in time ( < < >>). From this aspect, GTS can generate all occurrence intervals of an event or action, or all validity periods for a fact. GTS as an expression-syntax defined for a calendar. This aspect is the GTS literal form. In all cases the GTS is defined as a set of point in time ( < >). Using the set operations, union, intersection and difference, more complex sets of time can be constructed from simpler ones. Ultimately the building blocks from which all GTS values are constructed are interval, periodic interval, and event-related periodic interval. The construction of the GTS can be specified in the literal form. No special data type structure is defined that would generate a combination of simpler time-sets from a given GTS value. While any implementation would have to contain such a structured representation, it is not needed in order to exchange GTS values given the literal form. The GTS is an example of a data type that is only defined algebraically without giving any definition of a data structure that might implement the behavior of such a data type. The algebraic definition looks extremely simple, so that one might assume it is incomplete. Since at this point we are relying entirely on the literal form to represent GTS values, all the definition of data structur The GTS data type is defined as using intervals, periodic intervals, and event-related periodic intervals. Intervals of time have been defined above A convex hull is the least interval that is a superset of all occurrence intervals. As noted in , all totally ordered sets have a convex hull. Because a GTS is a <> and because a <> is a totally ordered set, all GTS values have a convex hull. The convex hull of a GTS can less formally be called "outer bound interval". Thus, the convex hull of a GTS describes the absolute beginning and end of the repeating schedule. For infinite repetitions (e.g., a simple periodic interval) the convex hull has infinite bounds. Convex Hull of a Schedule A value is a generator of a sequence of time intervals during which an event or activity occurs, or during which a state is effective. The nextTo-property maps to every point in time t the greatest continuous subset (an "occurrence interval") v of the value S, where v is the interval closest to t that begins later than t or that contains t. invariant(GTS S, TS t, IVL<TS> v) { v.equal(S.nextTo(t)).equal( S.contains(o) .and(forall(IVL<TS> u) where x.contains(u) { u.contains(v).implies(u.equal(v)); }) .and( v.contains(t) .or(forall(TS i) where t.lessOrEqual(i) .and(i.lessThan(v.low)) { S.conatins(i).not; }))); }; The nextAfter-property maps to every point in time t the greatest continuous subset (an "occurrence interval") v of the value S, where v is the interval closest to t that begins later than t. invariant(GTS S, TS t) where { S.contains(t).not .implies(S.nextAfter(t).equal(S.nextTo(t))); S.contains(t) .implies(S.nextAfter(t).equal( S.except(nextTo(t)).nextTo(t))); }; A value can be converted into a generic Sequence of time intervals (<>) of occurrence intervals. invariant(GTS x) where x.isEmpty { ((LIST<IVL<TS>>)x).isEmpty; }; invariant(GTS x, IVL<TS> first) where x.notEmpty .and(x.hull.low.nonNull) .and(first.equal(x.nextTo(x.hull.low)) { ((LIST<IVL<TS>>)x).head.equal(first); ((LIST<IVL<TS>>)x).tail.equal( (LIST<IVL<TS>>)x.except(first)); }; Interleaving Schedules and Periodic Hull For two values A and B we say that A interleaves B if their occurrence intervals interleave on the time line. This concept is visualized in Figure 15. For the values A and B to interleave the occurrence intervals of both groups can be arranged in pairs of corresponding occurrence intervals. It must further hold that for all corresponding occurrence intervals a ? A and b ? B, a starts before b starts (or at the same time) and b ends after a ends (or at the same time). The interleaves-relation holds when two schedules have the same average frequency, and when the second schedule never "outpaces" the first schedule. That is, no occurrence interval in the second schedule may start before its corresponding occurrence interval in the first schedule. With two interleaving values one can derive a periodic hull such that the occurrence intervals of the periodic hull is the convex hull of the corresponding occurrence intervals. The periodic hull is important to construct two schedules by combining expressions. For example, to construct the periodic interval from Memorial Day to Labor Day every year, one first needs to set up the schedules M for Memorial Day (the last Monday in May) and L for Labor Day (the first Monday in September) and then combine these two schedules using the periodic hull of M and L. invariant(GTS A, B) where x.nonNull.and(y.nonNull) { A.interleaves(B).equal( forall(IVL<TS> a, b, c; TS t) where a.equal(A.nextTo(t)) .and(b.equal(B.nextTo(a.low))) .and(c.equal(A.nextTo(b.high))) { b.equal(B.nextTo(a.high)); a.low.lessOrEqual(b.low); c.equal(A.nextTo(b.high)); c.equal(a).or(c.equal(A.nextAfter(a.high))); }); }; For two values A and B where A interleaves B, a periodic hull is defined as the pair wise convex hull of the corresponding occurrence intervals of A and B. invariant(GTS A, B, C) where A.interleaves(B) { A.periodicHull(B).equal(C).equal( forall(IVL<TS> a, b; TS t) where a.equal(A.nextTo(t)) .and(b.equal(B.nextTo(a.low))) { C.contains(c).equal(c.equal(a.hull(b))); }); }; The interleaves-relation is reflexive, asymmetric, and intransitive. The periodic hull operation is non-commutative and non-associative. The interleaves property may appear overly constrained. However, these constraints are reasonable for the use case for which the interleaves and periodic hull properties are defined. To safely and predictably combine two schedules one would want to know which of the operands sets the start points and which sets the endpoints of the periodic hull's occurrence intervals. type GeneralTimingSpecification alias GTS specializes SET<TS> { IVL<TS> hull; IVL<TS> nextTo(TS x); IVL<TS> nextAfter(TS x); GTS periodicHull(GTS x); BL interleaves(GTS x); demotion LIST<IVL<TS>>; literal ST; }; A set of points in time, specifying the timing of events and actions and the cyclical validity-patterns that may exist for certain kinds of information, such as phone numbers (evening, daytime), addresses (so called "snowbirds," residing closer to the equator during winter and farther from the equator during summer) and office hours. The GTS data type has the following aspects: GTS as a general set of points in time ( < >). From this aspect GTS answers whether any given point in time falls in the schedule described by the GTS value. GTS as the combination of multiple periodic intervals of time. This aspect describes how both simple and complex repeat-patterns are specified with the GTS. GTS as a generator of a sequence of intervals of point in time ( < < >>). From this aspect, GTS can generate all occurrence intervals of an event or action, or all validity periods for a fact. GTS as an expression-syntax defined for a calendar. This aspect is the GTS literal form. In all cases the GTS is defined as a set of point in time ( < >). Using the set operations, union, intersection and difference, more complex sets of time can be constructed from simpler ones. Ultimately the building blocks from which all GTS values are constructed are interval, periodic interval, and event-related periodic interval. The construction of the GTS can be specified in the literal form. No special data type structure is defined that would generate a combination of simpler time-sets from a given GTS value. While any implementation would have to contain such a structured representation, it is not needed in order to exchange GTS values given the literal form. The GTS is an example of a data type that is only defined algebraically without giving any definition of a data structure that might implement the behavior of such a data type. The algebraic definition looks extremely simple, so that one might assume it is incomplete. Since at this point we are relying entirely on the literal form to represent GTS values, all the definition of data structur The GTS data type is defined as using intervals, periodic intervals, and event-related periodic intervals. Intervals of time have been defined above A convex hull is the least interval that is a superset of all occurrence intervals. As noted in , all totally ordered sets have a convex hull. Because a GTS is a <> and because a <> is a totally ordered set, all GTS values have a convex hull. The convex hull of a GTS can less formally be called "outer bound interval". Thus, the convex hull of a GTS describes the absolute beginning and end of the repeating schedule. For infinite repetitions (e.g., a simple periodic interval) the convex hull has infinite bounds. Convex Hull of a Schedule A value is a generator of a sequence of time intervals during which an event or activity occurs, or during which a state is effective. The nextTo-property maps to every point in time t the greatest continuous subset (an "occurrence interval") v of the value S, where v is the interval closest to t that begins later than t or that contains t. invariant(GTS S, TS t, IVL<TS> v) { v.equal(S.nextTo(t)).equal( S.contains(o) .and(forall(IVL<TS> u) where x.contains(u) { u.contains(v).implies(u.equal(v)); }) .and( v.contains(t) .or(forall(TS i) where t.lessOrEqual(i) .and(i.lessThan(v.low)) { S.conatins(i).not; }))); }; The nextAfter-property maps to every point in time t the greatest continuous subset (an "occurrence interval") v of the value S, where v is the interval closest to t that begins later than t. invariant(GTS S, TS t) where { S.contains(t).not .implies(S.nextAfter(t).equal(S.nextTo(t))); S.contains(t) .implies(S.nextAfter(t).equal( S.except(nextTo(t)).nextTo(t))); }; A value can be converted into a generic Sequence of time intervals (<>) of occurrence intervals. invariant(GTS x) where x.isEmpty { ((LIST<IVL<TS>>)x).isEmpty; }; invariant(GTS x, IVL<TS> first) where x.notEmpty .and(x.hull.low.nonNull) .and(first.equal(x.nextTo(x.hull.low)) { ((LIST<IVL<TS>>)x).head.equal(first); ((LIST<IVL<TS>>)x).tail.equal( (LIST<IVL<TS>>)x.except(first)); }; Interleaving Schedules and Periodic Hull For two values A and B we say that A interleaves B if their occurrence intervals interleave on the time line. This concept is visualized in Figure 15. For the values A and B to interleave the occurrence intervals of both groups can be arranged in pairs of corresponding occurrence intervals. It must further hold that for all corresponding occurrence intervals a ? A and b ? B, a starts before b starts (or at the same time) and b ends after a ends (or at the same time). The interleaves-relation holds when two schedules have the same average frequency, and when the second schedule never "outpaces" the first schedule. That is, no occurrence interval in the second schedule may start before its corresponding occurrence interval in the first schedule. With two interleaving values one can derive a periodic hull such that the occurrence intervals of the periodic hull is the convex hull of the corresponding occurrence intervals. The periodic hull is important to construct two schedules by combining expressions. For example, to construct the periodic interval from Memorial Day to Labor Day every year, one first needs to set up the schedules M for Memorial Day (the last Monday in May) and L for Labor Day (the first Monday in September) and then combine these two schedules using the periodic hull of M and L. invariant(GTS A, B) where x.nonNull.and(y.nonNull) { A.interleaves(B).equal( forall(IVL<TS> a, b, c; TS t) where a.equal(A.nextTo(t)) .and(b.equal(B.nextTo(a.low))) .and(c.equal(A.nextTo(b.high))) { b.equal(B.nextTo(a.high)); a.low.lessOrEqual(b.low); c.equal(A.nextTo(b.high)); c.equal(a).or(c.equal(A.nextAfter(a.high))); }); }; For two values A and B where A interleaves B, a periodic hull is defined as the pair wise convex hull of the corresponding occurrence intervals of A and B. invariant(GTS A, B, C) where A.interleaves(B) { A.periodicHull(B).equal(C).equal( forall(IVL<TS> a, b; TS t) where a.equal(A.nextTo(t)) .and(b.equal(B.nextTo(a.low))) { C.contains(c).equal(c.equal(a.hull(b))); }); }; The interleaves-relation is reflexive, asymmetric, and intransitive. The periodic hull operation is non-commutative and non-associative. The interleaves property may appear overly constrained. However, these constraints are reasonable for the use case for which the interleaves and periodic hull properties are defined. To safely and predictably combine two schedules one would want to know which of the operands sets the start points and which sets the endpoints of the periodic hull's occurrence intervals. type GeneralTimingSpecification alias GTS specializes SET<TS> { IVL<TS> hull; IVL<TS> nextTo(TS x); IVL<TS> nextAfter(TS x); GTS periodicHull(GTS x); BL interleaves(GTS x); demotion LIST<IVL<TS>>; literal ST; }; A set of points in time, specifying the timing of events and actions and the cyclical validity-patterns that may exist for certain kinds of information, such as phone numbers (evening, daytime), addresses (so called "snowbirds," residing closer to the equator during winter and farther from the equator during summer) and office hours. The GTS data type has the following aspects: GTS as a general set of points in time ( < >). From this aspect GTS answers whether any given point in time falls in the schedule described by the GTS value. GTS as the combination of multiple periodic intervals of time. This aspect describes how both simple and complex repeat-patterns are specified with the GTS. GTS as a generator of a sequence of intervals of point in time ( < < >>). From this aspect, GTS can generate all occurrence intervals of an event or action, or all validity periods for a fact. GTS as an expression-syntax defined for a calendar. This aspect is the GTS literal form. In all cases the GTS is defined as a set of point in time ( < >). Using the set operations, union, intersection and difference, more complex sets of time can be constructed from simpler ones. Ultimately the building blocks from which all GTS values are constructed are interval, periodic interval, and event-related periodic interval. The construction of the GTS can be specified in the literal form. No special data type structure is defined that would generate a combination of simpler time-sets from a given GTS value. While any implementation would have to contain such a structured representation, it is not needed in order to exchange GTS values given the literal form. The GTS is an example of a data type that is only defined algebraically without giving any definition of a data structure that might implement the behavior of such a data type. The algebraic definition looks extremely simple, so that one might assume it is incomplete. Since at this point we are relying entirely on the literal form to represent GTS values, all the definition of data structur The GTS data type is defined as using intervals, periodic intervals, and event-related periodic intervals. Intervals of time have been defined above A convex hull is the least interval that is a superset of all occurrence intervals. As noted in , all totally ordered sets have a convex hull. Because a GTS is a <> and because a <> is a totally ordered set, all GTS values have a convex hull. The convex hull of a GTS can less formally be called "outer bound interval". Thus, the convex hull of a GTS describes the absolute beginning and end of the repeating schedule. For infinite repetitions (e.g., a simple periodic interval) the convex hull has infinite bounds. Convex Hull of a Schedule A value is a generator of a sequence of time intervals during which an event or activity occurs, or during which a state is effective. The nextTo-property maps to every point in time t the greatest continuous subset (an "occurrence interval") v of the value S, where v is the interval closest to t that begins later than t or that contains t. invariant(GTS S, TS t, IVL<TS> v) { v.equal(S.nextTo(t)).equal( S.contains(o) .and(forall(IVL<TS> u) where x.contains(u) { u.contains(v).implies(u.equal(v)); }) .and( v.contains(t) .or(forall(TS i) where t.lessOrEqual(i) .and(i.lessThan(v.low)) { S.conatins(i).not; }))); }; The nextAfter-property maps to every point in time t the greatest continuous subset (an "occurrence interval") v of the value S, where v is the interval closest to t that begins later than t. invariant(GTS S, TS t) where { S.contains(t).not .implies(S.nextAfter(t).equal(S.nextTo(t))); S.contains(t) .implies(S.nextAfter(t).equal( S.except(nextTo(t)).nextTo(t))); }; A value can be converted into a generic Sequence of time intervals (<>) of occurrence intervals. invariant(GTS x) where x.isEmpty { ((LIST<IVL<TS>>)x).isEmpty; }; invariant(GTS x, IVL<TS> first) where x.notEmpty .and(x.hull.low.nonNull) .and(first.equal(x.nextTo(x.hull.low)) { ((LIST<IVL<TS>>)x).head.equal(first); ((LIST<IVL<TS>>)x).tail.equal( (LIST<IVL<TS>>)x.except(first)); }; Interleaving Schedules and Periodic Hull For two values A and B we say that A interleaves B if their occurrence intervals interleave on the time line. This concept is visualized in Figure 15. For the values A and B to interleave the occurrence intervals of both groups can be arranged in pairs of corresponding occurrence intervals. It must further hold that for all corresponding occurrence intervals a ? A and b ? B, a starts before b starts (or at the same time) and b ends after a ends (or at the same time). The interleaves-relation holds when two schedules have the same average frequency, and when the second schedule never "outpaces" the first schedule. That is, no occurrence interval in the second schedule may start before its corresponding occurrence interval in the first schedule. With two interleaving values one can derive a periodic hull such that the occurrence intervals of the periodic hull is the convex hull of the corresponding occurrence intervals. The periodic hull is important to construct two schedules by combining expressions. For example, to construct the periodic interval from Memorial Day to Labor Day every year, one first needs to set up the schedules M for Memorial Day (the last Monday in May) and L for Labor Day (the first Monday in September) and then combine these two schedules using the periodic hull of M and L. invariant(GTS A, B) where x.nonNull.and(y.nonNull) { A.interleaves(B).equal( forall(IVL<TS> a, b, c; TS t) where a.equal(A.nextTo(t)) .and(b.equal(B.nextTo(a.low))) .and(c.equal(A.nextTo(b.high))) { b.equal(B.nextTo(a.high)); a.low.lessOrEqual(b.low); c.equal(A.nextTo(b.high)); c.equal(a).or(c.equal(A.nextAfter(a.high))); }); }; For two values A and B where A interleaves B, a periodic hull is defined as the pair wise convex hull of the corresponding occurrence intervals of A and B. invariant(GTS A, B, C) where A.interleaves(B) { A.periodicHull(B).equal(C).equal( forall(IVL<TS> a, b; TS t) where a.equal(A.nextTo(t)) .and(b.equal(B.nextTo(a.low))) { C.contains(c).equal(c.equal(a.hull(b))); }); }; The interleaves-relation is reflexive, asymmetric, and intransitive. The periodic hull operation is non-commutative and non-associative. The interleaves property may appear overly constrained. However, these constraints are reasonable for the use case for which the interleaves and periodic hull properties are defined. To safely and predictably combine two schedules one would want to know which of the operands sets the start points and which sets the endpoints of the periodic hull's occurrence intervals. type GeneralTimingSpecification alias GTS specializes SET<TS> { IVL<TS> hull; IVL<TS> nextTo(TS x); IVL<TS> nextAfter(TS x); GTS periodicHull(GTS x); BL interleaves(GTS x); demotion LIST<IVL<TS>>; literal ST; }; A set of points in time, specifying the timing of events and actions and the cyclical validity-patterns that may exist for certain kinds of information, such as phone numbers (evening, daytime), addresses (so called "snowbirds," residing closer to the equator during winter and farther from the equator during summer) and office hours. The GTS data type has the following aspects: GTS as a general set of points in time ( < >). From this aspect GTS answers whether any given point in time falls in the schedule described by the GTS value. GTS as the combination of multiple periodic intervals of time. This aspect describes how both simple and complex repeat-patterns are specified with the GTS. GTS as a generator of a sequence of intervals of point in time ( < < >>). From this aspect, GTS can generate all occurrence intervals of an event or action, or all validity periods for a fact. GTS as an expression-syntax defined for a calendar. This aspect is the GTS literal form. In all cases the GTS is defined as a set of point in time ( < >). Using the set operations, union, intersection and difference, more complex sets of time can be constructed from simpler ones. Ultimately the building blocks from which all GTS values are constructed are interval, periodic interval, and event-related periodic interval. The construction of the GTS can be specified in the literal form. No special data type structure is defined that would generate a combination of simpler time-sets from a given GTS value. While any implementation would have to contain such a structured representation, it is not needed in order to exchange GTS values given the literal form. The GTS is an example of a data type that is only defined algebraically without giving any definition of a data structure that might implement the behavior of such a data type. The algebraic definition looks extremely simple, so that one might assume it is incomplete. Since at this point we are relying entirely on the literal form to represent GTS values, all the definition of data structur The GTS data type is defined as using intervals, periodic intervals, and event-related periodic intervals. Intervals of time have been defined above A convex hull is the least interval that is a superset of all occurrence intervals. As noted in , all totally ordered sets have a convex hull. Because a GTS is a <> and because a <> is a totally ordered set, all GTS values have a convex hull. The convex hull of a GTS can less formally be called "outer bound interval". Thus, the convex hull of a GTS describes the absolute beginning and end of the repeating schedule. For infinite repetitions (e.g., a simple periodic interval) the convex hull has infinite bounds. Convex Hull of a Schedule A value is a generator of a sequence of time intervals during which an event or activity occurs, or during which a state is effective. The nextTo-property maps to every point in time t the greatest continuous subset (an "occurrence interval") v of the value S, where v is the interval closest to t that begins later than t or that contains t. invariant(GTS S, TS t, IVL<TS> v) { v.equal(S.nextTo(t)).equal( S.contains(o) .and(forall(IVL<TS> u) where x.contains(u) { u.contains(v).implies(u.equal(v)); }) .and( v.contains(t) .or(forall(TS i) where t.lessOrEqual(i) .and(i.lessThan(v.low)) { S.conatins(i).not; }))); }; The nextAfter-property maps to every point in time t the greatest continuous subset (an "occurrence interval") v of the value S, where v is the interval closest to t that begins later than t. invariant(GTS S, TS t) where { S.contains(t).not .implies(S.nextAfter(t).equal(S.nextTo(t))); S.contains(t) .implies(S.nextAfter(t).equal( S.except(nextTo(t)).nextTo(t))); }; A value can be converted into a generic Sequence of time intervals (<>) of occurrence intervals. invariant(GTS x) where x.isEmpty { ((LIST<IVL<TS>>)x).isEmpty; }; invariant(GTS x, IVL<TS> first) where x.notEmpty .and(x.hull.low.nonNull) .and(first.equal(x.nextTo(x.hull.low)) { ((LIST<IVL<TS>>)x).head.equal(first); ((LIST<IVL<TS>>)x).tail.equal( (LIST<IVL<TS>>)x.except(first)); }; Interleaving Schedules and Periodic Hull For two values A and B we say that A interleaves B if their occurrence intervals interleave on the time line. This concept is visualized in Figure 15. For the values A and B to interleave the occurrence intervals of both groups can be arranged in pairs of corresponding occurrence intervals. It must further hold that for all corresponding occurrence intervals a ? A and b ? B, a starts before b starts (or at the same time) and b ends after a ends (or at the same time). The interleaves-relation holds when two schedules have the same average frequency, and when the second schedule never "outpaces" the first schedule. That is, no occurrence interval in the second schedule may start before its corresponding occurrence interval in the first schedule. With two interleaving values one can derive a periodic hull such that the occurrence intervals of the periodic hull is the convex hull of the corresponding occurrence intervals. The periodic hull is important to construct two schedules by combining expressions. For example, to construct the periodic interval from Memorial Day to Labor Day every year, one first needs to set up the schedules M for Memorial Day (the last Monday in May) and L for Labor Day (the first Monday in September) and then combine these two schedules using the periodic hull of M and L. invariant(GTS A, B) where x.nonNull.and(y.nonNull) { A.interleaves(B).equal( forall(IVL<TS> a, b, c; TS t) where a.equal(A.nextTo(t)) .and(b.equal(B.nextTo(a.low))) .and(c.equal(A.nextTo(b.high))) { b.equal(B.nextTo(a.high)); a.low.lessOrEqual(b.low); c.equal(A.nextTo(b.high)); c.equal(a).or(c.equal(A.nextAfter(a.high))); }); }; For two values A and B where A interleaves B, a periodic hull is defined as the pair wise convex hull of the corresponding occurrence intervals of A and B. invariant(GTS A, B, C) where A.interleaves(B) { A.periodicHull(B).equal(C).equal( forall(IVL<TS> a, b; TS t) where a.equal(A.nextTo(t)) .and(b.equal(B.nextTo(a.low))) { C.contains(c).equal(c.equal(a.hull(b))); }); }; The interleaves-relation is reflexive, asymmetric, and intransitive. The periodic hull operation is non-commutative and non-associative. The interleaves property may appear overly constrained. However, these constraints are reasonable for the use case for which the interleaves and periodic hull properties are defined. To safely and predictably combine two schedules one would want to know which of the operands sets the start points and which sets the endpoints of the periodic hull's occurrence intervals. type GeneralTimingSpecification alias GTS specializes SET<TS> { IVL<TS> hull; IVL<TS> nextTo(TS x); IVL<TS> nextAfter(TS x); GTS periodicHull(GTS x); BL interleaves(GTS x); demotion LIST<IVL<TS>>; literal ST; }; A set of points in time, specifying the timing of events and actions and the cyclical validity-patterns that may exist for certain kinds of information, such as phone numbers (evening, daytime), addresses (so called "snowbirds," residing closer to the equator during winter and farther from the equator during summer) and office hours. The GTS data type has the following aspects: GTS as a general set of points in time ( < >). From this aspect GTS answers whether any given point in time falls in the schedule described by the GTS value. GTS as the combination of multiple periodic intervals of time. This aspect describes how both simple and complex repeat-patterns are specified with the GTS. GTS as a generator of a sequence of intervals of point in time ( < < >>). From this aspect, GTS can generate all occurrence intervals of an event or action, or all validity periods for a fact. GTS as an expression-syntax defined for a calendar. This aspect is the GTS literal form. In all cases the GTS is defined as a set of point in time ( < >). Using the set operations, union, intersection and difference, more complex sets of time can be constructed from simpler ones. Ultimately the building blocks from which all GTS values are constructed are interval, periodic interval, and event-related periodic interval. The construction of the GTS can be specified in the literal form. No special data type structure is defined that would generate a combination of simpler time-sets from a given GTS value. While any implementation would have to contain such a structured representation, it is not needed in order to exchange GTS values given the literal form. The GTS is an example of a data type that is only defined algebraically without giving any definition of a data structure that might implement the behavior of such a data type. The algebraic definition looks extremely simple, so that one might assume it is incomplete. Since at this point we are relying entirely on the literal form to represent GTS values, all the definition of data structur The GTS data type is defined as using intervals, periodic intervals, and event-related periodic intervals. Intervals of time have been defined above A convex hull is the least interval that is a superset of all occurrence intervals. As noted in , all totally ordered sets have a convex hull. Because a GTS is a <> and because a <> is a totally ordered set, all GTS values have a convex hull. The convex hull of a GTS can less formally be called "outer bound interval". Thus, the convex hull of a GTS describes the absolute beginning and end of the repeating schedule. For infinite repetitions (e.g., a simple periodic interval) the convex hull has infinite bounds. Convex Hull of a Schedule A value is a generator of a sequence of time intervals during which an event or activity occurs, or during which a state is effective. The nextTo-property maps to every point in time t the greatest continuous subset (an "occurrence interval") v of the value S, where v is the interval closest to t that begins later than t or that contains t. invariant(GTS S, TS t, IVL<TS> v) { v.equal(S.nextTo(t)).equal( S.contains(o) .and(forall(IVL<TS> u) where x.contains(u) { u.contains(v).implies(u.equal(v)); }) .and( v.contains(t) .or(forall(TS i) where t.lessOrEqual(i) .and(i.lessThan(v.low)) { S.conatins(i).not; }))); }; The nextAfter-property maps to every point in time t the greatest continuous subset (an "occurrence interval") v of the value S, where v is the interval closest to t that begins later than t. invariant(GTS S, TS t) where { S.contains(t).not .implies(S.nextAfter(t).equal(S.nextTo(t))); S.contains(t) .implies(S.nextAfter(t).equal( S.except(nextTo(t)).nextTo(t))); }; A value can be converted into a generic Sequence of time intervals (<>) of occurrence intervals. invariant(GTS x) where x.isEmpty { ((LIST<IVL<TS>>)x).isEmpty; }; invariant(GTS x, IVL<TS> first) where x.notEmpty .and(x.hull.low.nonNull) .and(first.equal(x.nextTo(x.hull.low)) { ((LIST<IVL<TS>>)x).head.equal(first); ((LIST<IVL<TS>>)x).tail.equal( (LIST<IVL<TS>>)x.except(first)); }; Interleaving Schedules and Periodic Hull For two values A and B we say that A interleaves B if their occurrence intervals interleave on the time line. This concept is visualized in Figure 15. For the values A and B to interleave the occurrence intervals of both groups can be arranged in pairs of corresponding occurrence intervals. It must further hold that for all corresponding occurrence intervals a ? A and b ? B, a starts before b starts (or at the same time) and b ends after a ends (or at the same time). The interleaves-relation holds when two schedules have the same average frequency, and when the second schedule never "outpaces" the first schedule. That is, no occurrence interval in the second schedule may start before its corresponding occurrence interval in the first schedule. With two interleaving values one can derive a periodic hull such that the occurrence intervals of the periodic hull is the convex hull of the corresponding occurrence intervals. The periodic hull is important to construct two schedules by combining expressions. For example, to construct the periodic interval from Memorial Day to Labor Day every year, one first needs to set up the schedules M for Memorial Day (the last Monday in May) and L for Labor Day (the first Monday in September) and then combine these two schedules using the periodic hull of M and L. invariant(GTS A, B) where x.nonNull.and(y.nonNull) { A.interleaves(B).equal( forall(IVL<TS> a, b, c; TS t) where a.equal(A.nextTo(t)) .and(b.equal(B.nextTo(a.low))) .and(c.equal(A.nextTo(b.high))) { b.equal(B.nextTo(a.high)); a.low.lessOrEqual(b.low); c.equal(A.nextTo(b.high)); c.equal(a).or(c.equal(A.nextAfter(a.high))); }); }; For two values A and B where A interleaves B, a periodic hull is defined as the pair wise convex hull of the corresponding occurrence intervals of A and B. invariant(GTS A, B, C) where A.interleaves(B) { A.periodicHull(B).equal(C).equal( forall(IVL<TS> a, b; TS t) where a.equal(A.nextTo(t)) .and(b.equal(B.nextTo(a.low))) { C.contains(c).equal(c.equal(a.hull(b))); }); }; The interleaves-relation is reflexive, asymmetric, and intransitive. The periodic hull operation is non-commutative and non-associative. The interleaves property may appear overly constrained. However, these constraints are reasonable for the use case for which the interleaves and periodic hull properties are defined. To safely and predictably combine two schedules one would want to know which of the operands sets the start points and which sets the endpoints of the periodic hull's occurrence intervals. type GeneralTimingSpecification alias GTS specializes SET<TS> { IVL<TS> hull; IVL<TS> nextTo(TS x); IVL<TS> nextAfter(TS x); GTS periodicHull(GTS x); BL interleaves(GTS x); demotion LIST<IVL<TS>>; literal ST; }; A set of points in time, specifying the timing of events and actions and the cyclical validity-patterns that may exist for certain kinds of information, such as phone numbers (evening, daytime), addresses (so called "snowbirds," residing closer to the equator during winter and farther from the equator during summer) and office hours. The GTS data type has the following aspects: GTS as a general set of points in time ( < >). From this aspect GTS answers whether any given point in time falls in the schedule described by the GTS value. GTS as the combination of multiple periodic intervals of time. This aspect describes how both simple and complex repeat-patterns are specified with the GTS. GTS as a generator of a sequence of intervals of point in time ( < < >>). From this aspect, GTS can generate all occurrence intervals of an event or action, or all validity periods for a fact. GTS as an expression-syntax defined for a calendar. This aspect is the GTS literal form. In all cases the GTS is defined as a set of point in time ( < >). Using the set operations, union, intersection and difference, more complex sets of time can be constructed from simpler ones. Ultimately the building blocks from which all GTS values are constructed are interval, periodic interval, and event-related periodic interval. The construction of the GTS can be specified in the literal form. No special data type structure is defined that would generate a combination of simpler time-sets from a given GTS value. While any implementation would have to contain such a structured representation, it is not needed in order to exchange GTS values given the literal form. The GTS is an example of a data type that is only defined algebraically without giving any definition of a data structure that might implement the behavior of such a data type. The algebraic definition looks extremely simple, so that one might assume it is incomplete. Since at this point we are relying entirely on the literal form to represent GTS values, all the definition of data structur The GTS data type is defined as using intervals, periodic intervals, and event-related periodic intervals. Intervals of time have been defined above A convex hull is the least interval that is a superset of all occurrence intervals. As noted in , all totally ordered sets have a convex hull. Because a GTS is a <> and because a <> is a totally ordered set, all GTS values have a convex hull. The convex hull of a GTS can less formally be called "outer bound interval". Thus, the convex hull of a GTS describes the absolute beginning and end of the repeating schedule. For infinite repetitions (e.g., a simple periodic interval) the convex hull has infinite bounds. Convex Hull of a Schedule A value is a generator of a sequence of time intervals during which an event or activity occurs, or during which a state is effective. The nextTo-property maps to every point in time t the greatest continuous subset (an "occurrence interval") v of the value S, where v is the interval closest to t that begins later than t or that contains t. invariant(GTS S, TS t, IVL<TS> v) { v.equal(S.nextTo(t)).equal( S.contains(o) .and(forall(IVL<TS> u) where x.contains(u) { u.contains(v).implies(u.equal(v)); }) .and( v.contains(t) .or(forall(TS i) where t.lessOrEqual(i) .and(i.lessThan(v.low)) { S.conatins(i).not; }))); }; The nextAfter-property maps to every point in time t the greatest continuous subset (an "occurrence interval") v of the value S, where v is the interval closest to t that begins later than t. invariant(GTS S, TS t) where { S.contains(t).not .implies(S.nextAfter(t).equal(S.nextTo(t))); S.contains(t) .implies(S.nextAfter(t).equal( S.except(nextTo(t)).nextTo(t))); }; A value can be converted into a generic Sequence of time intervals (<>) of occurrence intervals. invariant(GTS x) where x.isEmpty { ((LIST<IVL<TS>>)x).isEmpty; }; invariant(GTS x, IVL<TS> first) where x.notEmpty .and(x.hull.low.nonNull) .and(first.equal(x.nextTo(x.hull.low)) { ((LIST<IVL<TS>>)x).head.equal(first); ((LIST<IVL<TS>>)x).tail.equal( (LIST<IVL<TS>>)x.except(first)); }; Interleaving Schedules and Periodic Hull For two values A and B we say that A interleaves B if their occurrence intervals interleave on the time line. This concept is visualized in Figure 15. For the values A and B to interleave the occurrence intervals of both groups can be arranged in pairs of corresponding occurrence intervals. It must further hold that for all corresponding occurrence intervals a ? A and b ? B, a starts before b starts (or at the same time) and b ends after a ends (or at the same time). The interleaves-relation holds when two schedules have the same average frequency, and when the second schedule never "outpaces" the first schedule. That is, no occurrence interval in the second schedule may start before its corresponding occurrence interval in the first schedule. With two interleaving values one can derive a periodic hull such that the occurrence intervals of the periodic hull is the convex hull of the corresponding occurrence intervals. The periodic hull is important to construct two schedules by combining expressions. For example, to construct the periodic interval from Memorial Day to Labor Day every year, one first needs to set up the schedules M for Memorial Day (the last Monday in May) and L for Labor Day (the first Monday in September) and then combine these two schedules using the periodic hull of M and L. invariant(GTS A, B) where x.nonNull.and(y.nonNull) { A.interleaves(B).equal( forall(IVL<TS> a, b, c; TS t) where a.equal(A.nextTo(t)) .and(b.equal(B.nextTo(a.low))) .and(c.equal(A.nextTo(b.high))) { b.equal(B.nextTo(a.high)); a.low.lessOrEqual(b.low); c.equal(A.nextTo(b.high)); c.equal(a).or(c.equal(A.nextAfter(a.high))); }); }; For two values A and B where A interleaves B, a periodic hull is defined as the pair wise convex hull of the corresponding occurrence intervals of A and B. invariant(GTS A, B, C) where A.interleaves(B) { A.periodicHull(B).equal(C).equal( forall(IVL<TS> a, b; TS t) where a.equal(A.nextTo(t)) .and(b.equal(B.nextTo(a.low))) { C.contains(c).equal(c.equal(a.hull(b))); }); }; The interleaves-relation is reflexive, asymmetric, and intransitive. The periodic hull operation is non-commutative and non-associative. The interleaves property may appear overly constrained. However, these constraints are reasonable for the use case for which the interleaves and periodic hull properties are defined. To safely and predictably combine two schedules one would want to know which of the operands sets the start points and which sets the endpoints of the periodic hull's occurrence intervals. type GeneralTimingSpecification alias GTS specializes SET<TS> { IVL<TS> hull; IVL<TS> nextTo(TS x); IVL<TS> nextAfter(TS x); GTS periodicHull(GTS x); BL interleaves(GTS x); demotion LIST<IVL<TS>>; literal ST; }; A set of points in time, specifying the timing of events and actions and the cyclical validity-patterns that may exist for certain kinds of information, such as phone numbers (evening, daytime), addresses (so called "snowbirds," residing closer to the equator during winter and farther from the equator during summer) and office hours. The GTS data type has the following aspects: GTS as a general set of points in time ( < >). From this aspect GTS answers whether any given point in time falls in the schedule described by the GTS value. GTS as the combination of multiple periodic intervals of time. This aspect describes how both simple and complex repeat-patterns are specified with the GTS. GTS as a generator of a sequence of intervals of point in time ( < < >>). From this aspect, GTS can generate all occurrence intervals of an event or action, or all validity periods for a fact. GTS as an expression-syntax defined for a calendar. This aspect is the GTS literal form. In all cases the GTS is defined as a set of point in time ( < >). Using the set operations, union, intersection and difference, more complex sets of time can be constructed from simpler ones. Ultimately the building blocks from which all GTS values are constructed are interval, periodic interval, and event-related periodic interval. The construction of the GTS can be specified in the literal form. No special data type structure is defined that would generate a combination of simpler time-sets from a given GTS value. While any implementation would have to contain such a structured representation, it is not needed in order to exchange GTS values given the literal form. The GTS is an example of a data type that is only defined algebraically without giving any definition of a data structure that might implement the behavior of such a data type. The algebraic definition looks extremely simple, so that one might assume it is incomplete. Since at this point we are relying entirely on the literal form to represent GTS values, all the definition of data structur The GTS data type is defined as using intervals, periodic intervals, and event-related periodic intervals. Intervals of time have been defined above A convex hull is the least interval that is a superset of all occurrence intervals. As noted in , all totally ordered sets have a convex hull. Because a GTS is a <> and because a <> is a totally ordered set, all GTS values have a convex hull. The convex hull of a GTS can less formally be called "outer bound interval". Thus, the convex hull of a GTS describes the absolute beginning and end of the repeating schedule. For infinite repetitions (e.g., a simple periodic interval) the convex hull has infinite bounds. Convex Hull of a Schedule A value is a generator of a sequence of time intervals during which an event or activity occurs, or during which a state is effective. The nextTo-property maps to every point in time t the greatest continuous subset (an "occurrence interval") v of the value S, where v is the interval closest to t that begins later than t or that contains t. invariant(GTS S, TS t, IVL<TS> v) { v.equal(S.nextTo(t)).equal( S.contains(o) .and(forall(IVL<TS> u) where x.contains(u) { u.contains(v).implies(u.equal(v)); }) .and( v.contains(t) .or(forall(TS i) where t.lessOrEqual(i) .and(i.lessThan(v.low)) { S.conatins(i).not; }))); }; The nextAfter-property maps to every point in time t the greatest continuous subset (an "occurrence interval") v of the value S, where v is the interval closest to t that begins later than t. invariant(GTS S, TS t) where { S.contains(t).not .implies(S.nextAfter(t).equal(S.nextTo(t))); S.contains(t) .implies(S.nextAfter(t).equal( S.except(nextTo(t)).nextTo(t))); }; A value can be converted into a generic Sequence of time intervals (<>) of occurrence intervals. invariant(GTS x) where x.isEmpty { ((LIST<IVL<TS>>)x).isEmpty; }; invariant(GTS x, IVL<TS> first) where x.notEmpty .and(x.hull.low.nonNull) .and(first.equal(x.nextTo(x.hull.low)) { ((LIST<IVL<TS>>)x).head.equal(first); ((LIST<IVL<TS>>)x).tail.equal( (LIST<IVL<TS>>)x.except(first)); }; Interleaving Schedules and Periodic Hull For two values A and B we say that A interleaves B if their occurrence intervals interleave on the time line. This concept is visualized in Figure 15. For the values A and B to interleave the occurrence intervals of both groups can be arranged in pairs of corresponding occurrence intervals. It must further hold that for all corresponding occurrence intervals a ? A and b ? B, a starts before b starts (or at the same time) and b ends after a ends (or at the same time). The interleaves-relation holds when two schedules have the same average frequency, and when the second schedule never "outpaces" the first schedule. That is, no occurrence interval in the second schedule may start before its corresponding occurrence interval in the first schedule. With two interleaving values one can derive a periodic hull such that the occurrence intervals of the periodic hull is the convex hull of the corresponding occurrence intervals. The periodic hull is important to construct two schedules by combining expressions. For example, to construct the periodic interval from Memorial Day to Labor Day every year, one first needs to set up the schedules M for Memorial Day (the last Monday in May) and L for Labor Day (the first Monday in September) and then combine these two schedules using the periodic hull of M and L. invariant(GTS A, B) where x.nonNull.and(y.nonNull) { A.interleaves(B).equal( forall(IVL<TS> a, b, c; TS t) where a.equal(A.nextTo(t)) .and(b.equal(B.nextTo(a.low))) .and(c.equal(A.nextTo(b.high))) { b.equal(B.nextTo(a.high)); a.low.lessOrEqual(b.low); c.equal(A.nextTo(b.high)); c.equal(a).or(c.equal(A.nextAfter(a.high))); }); }; For two values A and B where A interleaves B, a periodic hull is defined as the pair wise convex hull of the corresponding occurrence intervals of A and B. invariant(GTS A, B, C) where A.interleaves(B) { A.periodicHull(B).equal(C).equal( forall(IVL<TS> a, b; TS t) where a.equal(A.nextTo(t)) .and(b.equal(B.nextTo(a.low))) { C.contains(c).equal(c.equal(a.hull(b))); }); }; The interleaves-relation is reflexive, asymmetric, and intransitive. The periodic hull operation is non-commutative and non-associative. The interleaves property may appear overly constrained. However, these constraints are reasonable for the use case for which the interleaves and periodic hull properties are defined. To safely and predictably combine two schedules one would want to know which of the operands sets the start points and which sets the endpoints of the periodic hull's occurrence intervals. type GeneralTimingSpecification alias GTS specializes SET<TS> { IVL<TS> hull; IVL<TS> nextTo(TS x); IVL<TS> nextAfter(TS x); GTS periodicHull(GTS x); BL interleaves(GTS x); demotion LIST<IVL<TS>>; literal ST; }; PPD (ParametricProbabilityDistribution) A generic data type extension specifying uncertainty of quantitative data using a distribution function and its parameters. Aside from the specific parameters of the distribution, a mean (expected value) and standard deviation is always given to help maintain a minimum layer of interoperability if receiving applications cannot deal with a certain probability distribution. For example, the most common college entrance exam in the United States is the SAT, which is comprised of two parts: verbal and math. Each part has a minimum score of 400 (no questions answered correctly) and a perfect score of 800. In 1998, according to the College Board, 1,172,779 college-bound seniors took the test. The mean score for the math portion of the test was 512, and the standard deviation 112. These parameter values (512, 112), tagged as the normal distribution parameters, paint a pretty good picture of test score distribution. In most cases, there is no need to specify all 1-million+ points of data when just 2 parameters will do! Note that the normal distribution is only one of several distributions defined for HL7. Since a specializes its parameter type T, a simple T value is the mean (expected value or first moment) of the probability distribution. Applications that cannot deal with distributions will take the simple T value neglecting the uncertainty. That simple value of type T is also used to standardize the data for computing the distribution. Probability distributions are defined over integer or real numbers and normalized to a certain reference point (typically zero) and reference unit (e.g., standard deviation = 1). When other quantities defined in this specification are used as base types, the mean and the standard deviation are used to scale the probability distribution. For example, if a of PQ for a length is given with mean 20 ft and a standard deviation of 2 in, the normalized distribution function f(x) that maps a real number x to a probability density would be translated to f'(x') that maps a length x' to a probability density as f'(x') = f((x' - ? ) / s). Where applicable, the specification conforms to the ISO Guide to the Expression of Uncertainty in Measurement (GUM) as reflected by NIST publication 1297 Guidelines for Evaluating and Expressing the Uncertainty of NIST Measurement Results. The specification does not describe how uncertainty is to be evaluated but only how it is expressed. The concept of "standard uncertainty" as set forth by the ISO GUM corresponds to the "standard deviation" property of the . template<QTY T> type ParametricProbabilityDistribution<T> alias PPD<T> specializes T { QTY standardDeviation; CS distributionType; literal ST; }; A generic data type extension specifying uncertainty of quantitative data using a distribution function and its parameters. Aside from the specific parameters of the distribution, a mean (expected value) and standard deviation is always given to help maintain a minimum layer of interoperability if receiving applications cannot deal with a certain probability distribution. For example, the most common college entrance exam in the United States is the SAT, which is comprised of two parts: verbal and math. Each part has a minimum score of 400 (no questions answered correctly) and a perfect score of 800. In 1998, according to the College Board, 1,172,779 college-bound seniors took the test. The mean score for the math portion of the test was 512, and the standard deviation 112. These parameter values (512, 112), tagged as the normal distribution parameters, paint a pretty good picture of test score distribution. In most cases, there is no need to specify all 1-million+ points of data when just 2 parameters will do! Note that the normal distribution is only one of several distributions defined for HL7. Since a specializes its parameter type T, a simple T value is the mean (expected value or first moment) of the probability distribution. Applications that cannot deal with distributions will take the simple T value neglecting the uncertainty. That simple value of type T is also used to standardize the data for computing the distribution. Probability distributions are defined over integer or real numbers and normalized to a certain reference point (typically zero) and reference unit (e.g., standard deviation = 1). When other quantities defined in this specification are used as base types, the mean and the standard deviation are used to scale the probability distribution. For example, if a of PQ for a length is given with mean 20 ft and a standard deviation of 2 in, the normalized distribution function f(x) that maps a real number x to a probability density would be translated to f'(x') that maps a length x' to a probability density as f'(x') = f((x' - ? ) / s). Where applicable, the specification conforms to the ISO Guide to the Expression of Uncertainty in Measurement (GUM) as reflected by NIST publication 1297 Guidelines for Evaluating and Expressing the Uncertainty of NIST Measurement Results. The specification does not describe how uncertainty is to be evaluated but only how it is expressed. The concept of "standard uncertainty" as set forth by the ISO GUM corresponds to the "standard deviation" property of the . template<QTY T> type ParametricProbabilityDistribution<T> alias PPD<T> specializes T { QTY standardDeviation; CS distributionType; literal ST; }; A generic data type extension specifying uncertainty of quantitative data using a distribution function and its parameters. Aside from the specific parameters of the distribution, a mean (expected value) and standard deviation is always given to help maintain a minimum layer of interoperability if receiving applications cannot deal with a certain probability distribution. For example, the most common college entrance exam in the United States is the SAT, which is comprised of two parts: verbal and math. Each part has a minimum score of 400 (no questions answered correctly) and a perfect score of 800. In 1998, according to the College Board, 1,172,779 college-bound seniors took the test. The mean score for the math portion of the test was 512, and the standard deviation 112. These parameter values (512, 112), tagged as the normal distribution parameters, paint a pretty good picture of test score distribution. In most cases, there is no need to specify all 1-million+ points of data when just 2 parameters will do! Note that the normal distribution is only one of several distributions defined for HL7. Since a specializes its parameter type T, a simple T value is the mean (expected value or first moment) of the probability distribution. Applications that cannot deal with distributions will take the simple T value neglecting the uncertainty. That simple value of type T is also used to standardize the data for computing the distribution. Probability distributions are defined over integer or real numbers and normalized to a certain reference point (typically zero) and reference unit (e.g., standard deviation = 1). When other quantities defined in this specification are used as base types, the mean and the standard deviation are used to scale the probability distribution. For example, if a of PQ for a length is given with mean 20 ft and a standard deviation of 2 in, the normalized distribution function f(x) that maps a real number x to a probability density would be translated to f'(x') that maps a length x' to a probability density as f'(x') = f((x' - ? ) / s). Where applicable, the specification conforms to the ISO Guide to the Expression of Uncertainty in Measurement (GUM) as reflected by NIST publication 1297 Guidelines for Evaluating and Expressing the Uncertainty of NIST Measurement Results. The specification does not describe how uncertainty is to be evaluated but only how it is expressed. The concept of "standard uncertainty" as set forth by the ISO GUM corresponds to the "standard deviation" property of the . template<QTY T> type ParametricProbabilityDistribution<T> alias PPD<T> specializes T { QTY standardDeviation; CS distributionType; literal ST; }; A generic data type extension specifying uncertainty of quantitative data using a distribution function and its parameters. Aside from the specific parameters of the distribution, a mean (expected value) and standard deviation is always given to help maintain a minimum layer of interoperability if receiving applications cannot deal with a certain probability distribution. For example, the most common college entrance exam in the United States is the SAT, which is comprised of two parts: verbal and math. Each part has a minimum score of 400 (no questions answered correctly) and a perfect score of 800. In 1998, according to the College Board, 1,172,779 college-bound seniors took the test. The mean score for the math portion of the test was 512, and the standard deviation 112. These parameter values (512, 112), tagged as the normal distribution parameters, paint a pretty good picture of test score distribution. In most cases, there is no need to specify all 1-million+ points of data when just 2 parameters will do! Note that the normal distribution is only one of several distributions defined for HL7. Since a specializes its parameter type T, a simple T value is the mean (expected value or first moment) of the probability distribution. Applications that cannot deal with distributions will take the simple T value neglecting the uncertainty. That simple value of type T is also used to standardize the data for computing the distribution. Probability distributions are defined over integer or real numbers and normalized to a certain reference point (typically zero) and reference unit (e.g., standard deviation = 1). When other quantities defined in this specification are used as base types, the mean and the standard deviation are used to scale the probability distribution. For example, if a of PQ for a length is given with mean 20 ft and a standard deviation of 2 in, the normalized distribution function f(x) that maps a real number x to a probability density would be translated to f'(x') that maps a length x' to a probability density as f'(x') = f((x' - ? ) / s). Where applicable, the specification conforms to the ISO Guide to the Expression of Uncertainty in Measurement (GUM) as reflected by NIST publication 1297 Guidelines for Evaluating and Expressing the Uncertainty of NIST Measurement Results. The specification does not describe how uncertainty is to be evaluated but only how it is expressed. The concept of "standard uncertainty" as set forth by the ISO GUM corresponds to the "standard deviation" property of the . template<QTY T> type ParametricProbabilityDistribution<T> alias PPD<T> specializes T { QTY standardDeviation; CS distributionType; literal ST; }; PPD_REAL (ParametricProbabilityDistribution<RealNumber>) The parametric probability distribution of real numbers is fully defined by the generic data type. However, there are some special considerations about literal representations and conversions of probability distributions over real numbers, which are specified in this section. When converting a into a , the standard deviation is calculated from the value's order of magnitude and precision (number of significant digits). Let x be a real number with precision n. We can determine the order of magnitude e of x as e = log10 |x| where e is rounded to the next integer that is closer to zero (special case: if x is zero, e is zero.) The value of least significant digit l is then l = 10e-n and the standard deviation s is s = l / 2. Examples of standard deviations computed from precision p and order of magnitude eRepresentationxepe - p + 1ls00(0)1010.51101010.52201010.59901010.5101012010.510010023010.51e+1101111051e+21002121005010e+11002211051.11.102-10.10.0510.110.113-10.10.051.1e+21102211051.1e-20.011-22-30.0010.00051.1e-40.00011-42-50.000010.00000510.1e-40.00101-33-50.000010.0000050.1e-10.01-21-20.010.0050.01e-10.001-31-30.0010.00050.01e-20.0001-41-40.00010.000050.000(0)3-20.010.005 type ParametricProbabilityDistribution<RealNumber> alias PPD<REAL> specializes PPD<T>; The parametric probability distribution of real numbers is fully defined by the generic data type. However, there are some special considerations about literal representations and conversions of probability distributions over real numbers, which are specified in this section. When converting a into a , the standard deviation is calculated from the value's order of magnitude and precision (number of significant digits). Let x be a real number with precision n. We can determine the order of magnitude e of x as e = log10 |x| where e is rounded to the next integer that is closer to zero (special case: if x is zero, e is zero.) The value of least significant digit l is then l = 10e-n and the standard deviation s is s = l / 2. Examples of standard deviations computed from precision p and order of magnitude eRepresentationxepe - p + 1ls00(0)1010.51101010.52201010.59901010.5101012010.510010023010.51e+1101111051e+21002121005010e+11002211051.11.102-10.10.0510.110.113-10.10.051.1e+21102211051.1e-20.011-22-30.0010.00051.1e-40.00011-42-50.000010.00000510.1e-40.00101-33-50.000010.0000050.1e-10.01-21-20.010.0050.01e-10.001-31-30.0010.00050.01e-20.0001-41-40.00010.000050.000(0)3-20.010.005 type ParametricProbabilityDistribution<RealNumber> alias PPD<REAL> specializes PPD<T>; PPD_PQ (ParametricProbabilityDistribution<PhysicalQuantity>) A parametric probability distribution over physical quantities is constructed from the generic type. However, recognizing that the unit can be factored from the boundaries, we add additional semantics and a separate literal form. The additional view of a probability distribution over physical quantities is a probability distribution over real numbers with one unit. The unit applies to both mean and standard deviation. type ParametricProbabilityDistribution<PhysicalQuantity> alias PPD<PQ> specializes PPD<T> { PPD<REAL> value; CS unit; }; A parametric probability distribution over physical quantities is constructed from the generic type. However, recognizing that the unit can be factored from the boundaries, we add additional semantics and a separate literal form. The additional view of a probability distribution over physical quantities is a probability distribution over real numbers with one unit. The unit applies to both mean and standard deviation. type ParametricProbabilityDistribution<PhysicalQuantity> alias PPD<PQ> specializes PPD<T> { PPD<REAL> value; CS unit; }; A parametric probability distribution over physical quantities is constructed from the generic type. However, recognizing that the unit can be factored from the boundaries, we add additional semantics and a separate literal form. The additional view of a probability distribution over physical quantities is a probability distribution over real numbers with one unit. The unit applies to both mean and standard deviation. type ParametricProbabilityDistribution<PhysicalQuantity> alias PPD<PQ> specializes PPD<T> { PPD<REAL> value; CS unit; }; A parametric probability distribution over physical quantities is constructed from the generic type. However, recognizing that the unit can be factored from the boundaries, we add additional semantics and a separate literal form. The additional view of a probability distribution over physical quantities is a probability distribution over real numbers with one unit. The unit applies to both mean and standard deviation. type ParametricProbabilityDistribution<PhysicalQuantity> alias PPD<PQ> specializes PPD<T> { PPD<REAL> value; CS unit; }; PPD_TS (ParametricProbabilityDistribution<PointInTime>) The parametric probability distribution over time points is fully defined by the generic data type. The standard deviation is of type TS.diffType, which is a duration (a physical quantity in the dimension of time.) When converting a into a <>, the standard deviation is calculated from the value's order of magnitude and precision (number of significant digits) such that two standard deviations span the maximal time range of the digits not specified. For example, in 20000609 the unspecified digits are hour of the day and lower. All these digits together span a duration of 24 hours, and thus, the standard deviation ( is( = 12 h from 20000609000000.0000... up to 20000609999999.9999... (= 20000610) This rule is different from real numbers in that the range of uncertainty lies above the time value specified. This is to go with the common sense judgment that June 9th spans all day of June 9th with noon as the center, not midnight. type ParametricProbabilityDistribution<PointInTime> alias PPD<TS> specializes PPD<T>;