This wiki has undergone a migration to Confluence found Here

Requirements-Data Types

From HL7Wiki
Jump to navigation Jump to search

V3 Data Types: Methodology Requirements

What's a data type? There is a variety of definitions, but they revolve around the following aspects:

  • Their value is their identity
  • they have no life-cycle
  • They derive from primitive types or collections
  • they are used as the types of attributes in UML models
  • their definition requires special considerations when implementing.

Of these, the first two are the important differentiators. The other three often follow, but are not required consequences.

This page details the requirements for the V3 data types definition infrastructure.

Preliminary Requirements

Requirement Must provide consistent design approach for all data types with clear semantic definitions
Rationale Previous experience, involving mixing and matching data types and definition approaches, has lead to much confusion and overhead when using them in standards development or implementatation.
Methodology Develop common architecture, strictly controlled definition templates, formal definition language

Requirement Must be able to define Data Types for all RIM Attributes
Rationale As presented here, the requirement for data types is secondary to the use of the RIM to solve other requirements, though it is likely that any other approach to solving the requirements that the RIM fulfills would lead to the creation of data types.
Methodology Existence of data types; controls the scope of the data types

Requirement Definitions must be technology neutral
Rationale The development and maintenance of the data types (along with the RIM) is expected to be on a slower cycle than the definition of technologies such as XML and UML, and we need to able deliver standards based on future technologies in a more timely fashion
Methodology Split between Abstract Data types - no technology dependence in the definitions, and the implementations, which are technology specific (and optimised)

Requirement Must be possible to implement the data types using common implementation technologies at this time.
Rationale People do actually have to use them.
Methodology Provision of XML and UML implementation specifications (and then the ISO datatypes, combining both)

While this document is focused on the definitional mechanisms for the data types, many of the semantic requirements and the general architecture of the data types flow from these requirements.

Definitional Requirements

Requirement Each data type must have a clearly defined scope and principles of use
Rationale Need to know what they are, what they aren't, and what you can do with them
Methodology Extensive Narrative definitions for each type

Requirement Each data type must have a formal, precise definition
Rationale Need a precise and unambiguous definition of the semantics of the type
Methodology Use DTDL to provide the definition

Requirement The relationship between types must be clearly specified
Rationale The specialization/gneralization relationship and parameterization of the data types is a key aspect of their functionality
Methodology Track gen/spec and paramerisation relationships explicitly

Requirement Each data type is described in terms of it's behaviour
Rationale We are not concerned with the implementation, what's inside the datatype, only how it behaves when it is handled
Methodology Define properties as operations on the data type. May take multiple parameters, return a value. Parameters and return value are also data types (consistency of design)

Requirement The exact signature of each property must be clear
Rationale Need to be clear about the definition
Methodology Define each parameter, it's type, and the return type explicitly, in DTDL and narrative

Requirement Each property has clearly described semantics
Rationale We need to known exactly how they behave
Methodology Mix of narrative, DTDL statements of truth, and tables of possible values for coded properties

Requirement Must be able to read the specification
Rationale Actual users need to read this specification, need to be able to understand it
Methodology Narrative, ability to manage the backbone and the indexes, provide UML diagrams to summarise the content

requirements for aspects of properties (terminology binding)

Data Type Flavors Requirements

Requirement Must be able to define reusable named constraints on data types
Rationale Defining general purpose data types with a broad range of functionality for interoperability creates a consistent desire to be able to narrow their usage in order to restrict implementation challenges in particular circumstances
Methodology Define data type flavors that constrain the value domain of a data type for a particular use; define methodology for using them (elsewhere)

Add requirement for transparency of use

Requirement Data type Flavor definitions must be clear
Rationale Need to know what the flavors have been defined for, who defined them, and what the scope of their authority is.
Methodology Clear definitions, scope part of name and definition.

Requirement The constraints for a flavor must be clearly stated
Rationale Need to know what the flavor does
Methodology DTDL (fail!)

Requirement The implementation path for a flavor must be clear
Rationale Need to actually make these do something
Methodology ? this is not done well