Requirements-Data Types

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 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	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 controled definition templates, formal definition language

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	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