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