oSIST prEN 16157-1:2024

SLOVENSKI STANDARD
01-september-2024
Inteligentni transportni sistemi - Specifikacije za izmenjavo podatkov DATEX II pri
upravljanju prometa in informiranju - 1. del: Skladnost in okvir
Intelligent transport systems — DATEX II data exchange specifications for traffic
management and information — Part 1: Context and framework
Intelligente Verkehrssysteme - DATEX II Datenaustauschspezifikation für
Verkehrsmanagement und Verkehrsinformation - Teil 1: Kontext und Rahmenwerk
Systèmes de transport intelligents — Spécifications DATEX II d'échange de données
pour la gestion du trafic et l'information routière — Partie 1: Contexte et cadre général
Ta slovenski standard je istoveten z: prEN 16157-1
ICS:
35.240.60 Uporabniške rešitve IT v IT applications in transport
prometu
2003-01.Slovenski inštitut za standardizacijo. Razmnoževanje celote ali delov tega standarda ni dovoljeno.

DRAFT
EUROPEAN STANDARD
NORME EUROPÉENNE
EUROPÄISCHE NORM
June 2024
ICS Will supersede EN 16157-1:2018
English Version
Intelligent transport systems - DATEX II data exchange
specifications for traffic management and information -
Part 1: Context and framework
Systèmes de transport intelligents - Spécifications Intelligente Verkehrssysteme - DATEX II
DATEX II d'échange de données pour la gestion du Datenaustauschspezifikation für Verkehrsmanagement
trafic et l'information routière - Partie 1: Contexte et und Verkehrsinformation - Teil 1: Kontext und
cadre général Rahmenwerk
This draft European Standard is submitted to CEN members for enquiry. It has been drawn up by the Technical Committee
CEN/TC 278.
If this draft becomes a European Standard, CEN members are bound to comply with the CEN/CENELEC Internal Regulations
which stipulate the conditions for giving this European Standard the status of a national standard without any alteration.

This draft European Standard was established by CEN in three official versions (English, French, German). A version in any other
language made by translation under the responsibility of a CEN member into its own language and notified to the CEN-CENELEC
Management Centre has the same status as the official versions.

CEN members are the national standards bodies of Austria, Belgium, Bulgaria, Croatia, Cyprus, Czech Republic, Denmark, Estonia,
Finland, France, Germany, Greece, Hungary, Iceland, Ireland, Italy, Latvia, Lithuania, Luxembourg, Malta, Netherlands, Norway,
Poland, Portugal, Republic of North Macedonia, Romania, Serbia, Slovakia, Slovenia, Spain, Sweden, Switzerland, Türkiye and
United Kingdom.
Recipients of this draft are invited to submit, with their comments, notification of any relevant patent rights of which they are
aware and to provide supporting documentation.

Warning : This document is not a European Standard. It is distributed for review and comments. It is subject to change without
notice and shall not be referred to as a European Standard.

EUROPEAN COMMITTEE FOR STANDARDIZATION
COMITÉ EUROPÉEN DE NORMALISATION

EUROPÄISCHES KOMITEE FÜR NORMUNG

CEN-CENELEC Management Centre: Rue de la Science 23, B-1040 Brussels
© 2024 CEN All rights of exploitation in any form and by any means reserved Ref. No. prEN 16157-1:2024 E
worldwide for CEN national Members.

Contents Page
European foreword . 3
Introduction . 4
1 Scope . 5
2 Normative references . 6
3 Terms and definitions . 6
4 Symbols and abbreviations . 9
5 General conventions and requirements . 9
6 Platform independent model rules . 13
7 Extension rules . 24
Annex A (normative) XML Schema Definition Mapping . 26
Bibliography . 41

prEN 16156-1:2024 (E)
European foreword
This document (EN 16157-1:2024) has been prepared by Technical Committee CEN/TC 278 “Intelligent
transport systems”, the secretariat of which is held by NEN.
This document is currently submitted to the CEN Enquiry.
This document will supersede EN 16157-1:2017.
EN 16157-1:2024 includes the following significant technical changes with respect to EN 16157-1:2017:
• Introduction of a new stereotype for entities
• Introduction of a new stereotype for codelists
• New reference mechanism with graphical representation in UML
• Complex datatypes can be set as type of UML attributes
• Bugfixes and improvements of phrasing
EN 16157-1 is the first part of a multi-part standard under the general title “Intelligent transport systems
— DATEX II data exchange specifications for traffic management and information”.
This document has been prepared under a standardization request addressed to CEN by the European
Commission. The Standing Committee of the EFTA States subsequently approves these requests for its
Member States.
Introduction
This document defines a common set of data exchange specifications to support the vision of a seamless
interoperable exchange of road traffic and travel information across boundaries, including national,
urban, interurban, road administrations, infrastructure providers and service providers. Standardization
in this context is a vital constituent to ensure interoperability, reduction of risk, reduction of the cost
base, promotion of open marketplaces and many social, economic and community benefits to be gained
from more informed travellers, network managers and transport operators.
Deploying Intelligent Transport Systems in line with European Sustainable and Smart Mobility Strategy
in achieving connected and automated multimodal mobility as issued by the European Commission
requires co-ordination of traffic management operation and development of seamless pan European
information services. These jointly aim at contributing to the transformation of the European transport
system to the objectives of efficient, safe, sustainable, smart and resilient mobility.
In this context the European Commission has been supporting the development of information exchange
between the actors of the road traffic management - and related services- domain for a several years. In
the road sector, DATEX II has been long in fruition, with the European Commission being fundamental to
its development through an initial contract and subsequent co-funding of the further evolution of the
standard and user support ecosystem. With this standardization of DATEX II, there is a real basis for
common exchange between the actors of the traffic and travel information sector both in the
collaboration between traffic management organisations and theirs systems, as well as in the coherent
way of information provision to service providers. DATEX II supports the requirements of the
stakeholder organisations involved in the road traffic and travel domain in compliance with the EU policy
and legal frameworks aimed at the sector.
The European Committee for Standardization (CEN) draws attention to the fact that it is claimed that
compliance with this document may involve the use of a patent concerning procedures, methods and/or
formats given in this document.
CEN takes no position concerning the evidence, validity and scope of patent rights.
This part of EN 16157 is targeted towards all stakeholders that want to understand the modelling
methodology applied throughout the DATEX II specifications. While this is potentially a wide range of
readers, the document addresses specifically those users that intend to extend the DATEX II data model
and therefore need to understand – and conform with – the modelling principles, the use of the Unified
Modelling Language (UML) and other conventions for DATEX II modelling.
Further to the UML modelling, this document also defines the mapping of this model to the eXtensible
Markup Language (XML), used for formatting data in DATEX II data exchanges. XML, being a widely used
method nowadays of formatting data for business-to-business data exchange over the Internet, is one of
the possible solutions for mapping the UML modelling into formatted data. Other methods like UPER
based on ASN.1 defined by ISO/IEC 8825-2 and JSON Schema defined by https://json-
schema.org/draft/2020-12/json-schema-core.html can also be considered and will potentially be
specified in further standards in this series. It should also be noted that this standard describes a
framework for DATEX II data that is usable for dynamic data messaging services. Other use cases like for
example map update exchange may benefit from other frameworks like e.g. Geography Markup Language
(GML). Thus, not all parts of the EN 16157 series will conform to all requirements of this document.
prEN 16156-1:2024 (E)
1 Scope
This document specifies and defines components required to support the exchange and shared use of
data and information in the field of traffic and travel.
The components include the framework and context for the modelling approach, data content, data
structure and relationships.
This document is applicable to:
— Traffic and travel information which is of relevance to road networks (non-urban and urban),
— Public transport information that is of direct relevance to the use of a road network (e.g. road link via
train or ferry service).
— Traffic and travel information in the case of Cooperative intelligent transport systems (C-ITS).
This document establishes specifications for data content to be exchanged between any two instances of
the following actors:
— Traffic Information Centres (TICs),
— Traffic Control Centres (TCCs),
— Service Providers (SPs),
Use of this document may be applicable for use by other actors.
The 16157 series of European Standards cover, at least, the following types of informational content:
— Road traffic event information – planned and unplanned occurrences both on the road network and
in the surrounding environment,
— Information about operator initiated actions – including both advisory and mandatory measures,
— Road traffic measurement data, status data, and travel time data,
— Travel information relevant to road users, including weather and environmental information,
— Road traffic management information and information and advice relating to use of the road network.
— Traffic Regulations
This part of EN 16157 specifies the DATEX II framework of all parts of this document, the context of use
and the modelling approach taken and used throughout these European Standards. This approach is
described using formal methods and provides the mandatory reference framework for all other parts.
2 Normative references
The following documents are referred to in the text in such a way that some or all of their content
constitutes requirements of this document. For dated references, only the edition cited applies. For
undated references, the latest edition of the referenced document (including any amendments) applies.
ISO/IEC 19505-1:2012, Information technology — Object Management Group Unified Modeling Language
(OMG UML) — Part 1: Infrastructure
ISO/IEC 14977:1996, Information technology — Syntactic metalanguage — Extended BNF
3 Terms and definitions
For the purposes of this document, the following terms and definitions apply.
ISO and IEC maintain terminology databases for use in standardization at the following addresses:
— ISO Online browsing platform: available at https://www.iso.org/obp/
— IEC Electropedia: available at https://www.electropedia.org/
NOTE Some Definitions in this clause have been taken from ISO/IEC 19505-1:2012 but have been adapted to
meet the particular use of UML within this specification.
3.1
association
semantic relationship between classes
3.2
attribute
named slot within a class that describes a range of values that instances of the class may hold
3.3
class
description of a set of objects that share the same attributes, relationships, and semantics
3.4
composition
association between two classes, where one class is a composite and the other is a part
Note 1 to entry: This characteristic is expressed in UML with an attribute named “isComposite” on the part end of
the Association being set to “true”.
3.5
dependency
implementation or functioning of one or more elements that requires the presence of one or more other
elements
3.6
enumeration
data type whose range is a list of predefined values, called enumeration literals
3.7
enumeration literal
element of the value space of an enumeration data type
prEN 16156-1:2024 (E)
3.8
generalization
taxonomic relationship between a more general element and a more specific element
3.9
multiplicity
range of integers specifying the allowable cardinalities for an instantiation of an element
Note 1 to entry: The upper bound of the range cannot be below the lower bound. The lower bound is a nonnegative
integer. The upper bound is a nonnegative integer or the special value unlimited, which indicates there is no upper
bound on the range.
3.10
package
grouping of model elements
3.11
UML profile
mechanism that allows metaclasses from existing metamodels to be extended to adapt them for different
purposes
Note 1 to entry: The term profile within the term UML profile has a different meaning than the term profile defined
in 3.27.
3.12
stereotype
concept provides a way of branding (classifying) model elements so that they behave in some respects as
if they were instances of new virtual metamodel constructs
3.13
binary (association)
association that connects exactly two classes
3.14
extension
set of data model elements not in the Level A domain and following the extension rules of DATEX II
3.15
Universally Unique Identifier
identifier that is unique in space and time, i.e. no other object will ever have the same identifier at any
other place and at any time
3.16
Lower Camel Case
description of the practice of concatenating compound phrases without whitespace in between where
phrases are delimited by upper case letters
Note 1 to entry: Lower Camel Case describes the case where the initial letter is lower case, e.g. as in lowerCamelCase.
3.17
model element
generic term for any construct of metadata used within a model to specify a particular aspect or element
of this model
3.18
Platform Independent Model
model of aspects of an information system (e.g. the data model) that is independent of any technical
platform used to implement the model
Note 1 to entry: Concrete implementations can be derived from the platform independent model by platform
specific models or mappings.
3.19
Platform Specific Model
model of aspects of an information system (e.g. the data model) that is linked to a specific technological
platform (e.g. a specific programming language or data transfer syntax)
3.20
publication
traffic related information or associated management information created at a specific point in time that
can be exchanged via a DATEX II interface
Note 1 to entry: The “PayloadPublication” class is the top level root class for DATEX II Level A.
3.21
Upper Camel Case
description of the practice of concatenating compound phrases without whitespace in between where
phrases are delimited by upper case letters
Note 1 to entry: Upper Camel Case describes the case where the initial letter is upper case, e.g. as in
UpperCamelCase.
3.22
Unique Resource Identifier
character string of well defined structure used to uniquely identify a resource
3.23
Unique Resource Locatore
Unique Resource Identifier actually pointing at a resource accessible via the Internet
3.24
eXtensible Markup Language
set of rules for encoding electronic documents defined by the World Wide Web Consortium W3C
Note 1 to entry: Although developed for documents, it is today widely used for data exchange in general, usually in
conjunction with an XML Schema Definition.
3.25
XML Metadata Interchange
XML based specification for the interoperable exchange of metadata
Note 1 to entry: It is today most commonly used to exchange UML models between UML tools. XMI is specified in
ISO/IEC 19508:2014.
prEN 16156-1:2024 (E)
3.26
XML Schema Definition
formal description of the allowed content of an XML document that claims to conform with the schema
Note 1 to entry: XML Schema Definitions allow for formal validation of syntactical conformity of instance
documents.
3.27
profile
selection of possible, optional elements
3.28
superclass
class directly related to the class of interest by a UML generalisation
3.29
namespace
identifier that specifies a set of unique names
3.30
facet
defining aspect of a value space
4 Symbols and abbreviations
UUID  Universally Unique identifier
LCC  Lower Camel Case
PIM  Platform Independent Model
PSM  Platform Specific Model
UCC  Upper Camel Case
UML  Unified Modelling Language
URI  Unique Resource Identifier
URL  Unique Resource Locator
W3C  World Wide Web Consortium
XML  eXtensible Markup Language
XMI  XML Metadata Interchange
XSD  XML Schema Definition
5 General conventions and requirements
5.1 Metamodelling
The DATEX II data modelling methodology uses the Unified Modelling Language (UML), version 2 as
specified in ISO/IEC 19505-1:2012. More accurately the release 2.4.1 of UML 2 is used.
UML provides a vast set of modelling elements that are not all used for DATEX II data modelling. In fact,
DATEX II uses a fairly small UML profile, based on the following metaclasses from the Core::Basic and
Core:Constructs packages specified in ISO/IEC 19505-1:2012:
— Association (stereotypes: D2Relation)
— Attribute (stereotypes: D2Attribute, D2Literal)
— Class (stereotypes: D2Class, D2Entity, D2EntityIdentifiable, D2EntityVersionedIdentifiable,
D2Identifiable, D2VersionedIdentifiable, D2ModelRoot, ExternalClass)
— DataType (stereotypes: D2Codelist, D2Datatype, ExternalType)
— Enumeration (stereotype: D2Enumeration)
— Generalization (some of them having the stereotype: D2LevelBExtension)
— Package (stereotypes: D2Package, D2Namespace, ExternalNamespace)
DATEX II specifies metadata for the metaclasses in a UML profile with stereotypes which are assigned to
the metaclasses, as listed above.
Simple types that may be assigned to attributes are defined as datatypes or enumerations.
Complex types (data structures) are defined as classes and may also be assigned to attributes as type.
Alternatively, they may be connected via a composition.
Generalization between classes is allowed, but multiple inheritance is prohibited, i.e. each class shall have
either zero or one superclass.
Classes, datatypes and enumerations may be structured in namespace packages, which define a
namespace for their contained classes, datatypes, enumerations and sub-packages. They may also be
structured simply in packages, which have no further semantics in DATEX II, they simply serve to
structure DATEX II models and make them more accessible.
Namespaces, classes and datatypes also have an option to refer to an external namespace, class or
datatype. The stereotypes defined for this purpose contain only the metadata required to refer to the
external entity. The specification of such external model elements is entirely out of the scope of this
document.
For readers not familiar with using UML or its graphical notations there is plenty of introductory material
available to learn about UML in general and we would like to refer the reader to these resources for
further study (e.g. to [1] or [2]). It should be noted that this document uses only the default graphical
representation of all UML elements used.
Note that no provisions are made regarding the existence and use of other UML elements. Thus, compliant
models may use these other elements, but they have no defined semantics in the framework of DATEX II.
The stereotypes of the DATEX II UML profile related to the platform independent model have defined
properties which are used in subsequent clauses to specify metamodel aspects. The allocation of which
properties are used by which stereotypes is depicted in the diagrams in clause 6. Further to that,
additional properties have been defined to govern the platform specific mapping to XML schema
definitions (ref. Annex A). Other property sets may be added to generate an alternative platform specific
model. Models that claim to conform with this specification may use these UML elements but shall
conform with all provisions regarding the use of these elements.
prEN 16156-1:2024 (E)
Note that the following list of properties constitutes the list of properties governed by this document.
Other properties may exist but are not governed by this document and have no semantics in the DATEX II
specifications.
5.2 DATEX II stereotype properties
5.2.1 Properties for the Platform Independent Model
definition: a clear, comprehensible and unambiguous definition of the modelled concept
description: a general textual reference and explanation of an external specification that is included in a
DATEX II model by using either classes with stereotype “ExternalNamespace”, “ExternalType” and/or
“ExternalClass”.
extensionName: the name of an extension if the model is extended
extensionVersion: the version of an extension if the model is extended
facets: the value of this property shall be a valid restriction of a “D2Datatype” DATEX II datatype
according to one of the facets defined in 6.5.8
modelBaseVersion: the number of the major component of a version number, e.g. “n” in case of version
number “n.m”
namespaceUri: a Universal Resource Identifier that uniquely identifies an external namespace
order: allows determining the order in which multiple metaclasses shall occur in a serialised structure of
a container
prefix: a prefix used to represent a namespace; to be used if the Platform Independent Model is mapped
to an implementation platform that supports the use of such prefixes
profileName: the name of a profile if the model is a profile
profileVersion: the version of a profile if the model is a profile
regulatoryContext: a description of any relevant regulatory context that governs the creation or the
structure of a metaclass, if applicable
rootElement: the indication for a mapping to a concrete platform to generate a top level element with the
class as type – where applicable - and using the property value as element name. If the platform has no
mechanism of defining such a top level element with a corresponding name, this property shall be ignored
schemaName: if this property is non-empty, mappings to specific platforms will have to use its value in
the mapping of the metaclass instead of the metaclass' own “name” attribute or any name following any
of the naming conventions provided in subsequent clauses of this document.
version: the full version number of the associated metaclass
5.2.2 Properties for the Platform Specific Model for XML schema definitions
schemaAttribute: if this property is set to “yes”, an attribute with simple type (datatype or enumeration)
from the platform independent model will be mapped to an XML attribute, if the property is empty or has
any other value, it will be mapped to an XML element
schemaLocation: A URL that points to an external XML schema that will be imported into the DATEX II
schema
NOTE These properties are specific to and their value is only considered in mapping to XML schema definitions
(XSD).
5.3 Naming conventions
5.3.1 All names used in DATEX II UML models shall conform with the following rule set.
5.3.2 The following UML constructs used in this document may have a name that is used by the DATEX
II metamodel: Attribute, Class, DataType, Enumeration, Package, Property. This name is specified via a
“name” metaattribute from that metaclass
If such a name metaattribute is provided, it shall begin with a letter, followed by none or more letters or
digits. A name is case sensitive.
In formal terms, a DATEX II name shall conform with the following definition using Extended Backus Naur
Form as of ISO/IEC 14977:1996.
name::= letter, { letter | digit }
letter::= “A” | “B” | “C” | “D” | “E” | “F” | “G” | “H” | “I” | “J” | “K” | “L” | “M”
| “N” | “O” | “P” | “Q” | “R” | “S” | “T” | “U” | “V” | “W” | “X” | “Y” | “Z” | “a” | “b”
| “c” | “d” | “e” | “f” | “g” | “h” | “i” | “j” | “k” | “l” | “m” | “n” | “o” | “p” | “q”
| “r” | “s” | “t” | “u” | “v” | “w” | “x” | “y” | “z”
digit::= “0” | “1” | “2” | “3” | “4” | “5” | “6” | “7” | “8” | “9”
5.3.3 The names of the instances of the following UML metaclasses shall be in Upper Camel Case
notation, i.e. they shall start with an upper case letter (‘A’ to ‘Z’), they shall consist of one or more logical
components, and each component itself shall again begin with an upper case letter (Example:
Component1Component2Component3):
Class, DataType, Enumeration, Package
5.3.4 The names of the instances of the following UML metaclasses shall be in Lower Camel Case
notation, i.e. they shall start with a lower case letter (‘a’ to ‘z’), they shall consist of one or more logical
components, and each component starting with the second component shall begin with an upper case
letter (Example: component1Component2Component3):
Attribute, Property
5.3.5 In all DATEX II names, acronyms should be avoided, but in cases where they are used, their
capitalization shall be modified to conform with the provisions in subclauses 5.3.3 and 5.3.4
NOTE In some parts of this document, default names are defined by turning names of other constructs from
Upper Camel Case to Lower Camel Case. This transformation is strictly defined as turning only the first character
from upper case to lower case. Example: a proper class name is “ANameExample”. If referred by another class via a
composition without role name and qualifier, the XML schema encoding of the enclosing class contains an attribute
that is implicitly named “aNameExample”.
5.3.6 The names of the following DATEX II UML constructs shall be unique in their namespace:
Class, DataType, Enumeration
5.3.7 To ensure that the mapping to platforms that do not allow any special characters is possible, the
upper-case letter “G” for ending a DATEX II name is reserved for the purpose of generating internal
names. Hence, a DATEX II name used in the UML model shall not end with the upper-case letter “G” to
avoid name collisions.
prEN 16156-1:2024 (E)
6 Platform independent model rules
6.1 General
The DATEX II modelling methodology implies a certain structure of a UML model that seeks to claim
conformity with this document. This subclause states the requirements that UML models shall conform
with in terms of constraints on the use of certain UML constructs. Note that no statements are made
concerning other UML constructs, i.e. models that contain other UML constructs may still claim DATEX II
conformity, as long as all requirements for the named UML constructs are met.
Most provisions in this clause have been directly deduced from the UML profile for DATEX II, which has
been introduced in subclause 5.1. Nevertheless, others have been decided deliberately to guide users,
improve modelling quality and avoid ambiguity.
The provisions in this subclause address the particular requirements for the platform independent
model, i.e. they do not address requirements for mapping DATEX II models to specific transfer syntax for
exchange of data. Such requirements are dealt with in later clauses of this document.
6.2 Requirements on associations
6.2.1 Figure 1depicts the stereotype “D2Relation” defined for DATEX II associations (in this case
associations with Association.memberEnd.isComposite = true; this is why DATEX II associations are
depicted as “Composition”).
Figure 1 – Associations
6.2.2 DATEX II models may contain UML Core::Constructs::Association with two memberEnd instances
(i.e. binary association) where one memberEnd.isComposite attribute set to “true”. Such binary
compositions may have a “D2Relation” stereotype from the “UML Profile for DATEX II” assigned to it.
Binary compositions with this stereotype assigned are called “DATEX II relations” for brevity in the rest
of this document.
6.2.3 DATEX II models may contain UML Core::Constructs::Association that have no “D2Relation”
stereotype or have other stereotypes assigned. Associations without “D2Relation” stereotype assigned
and other stereotypes on associations are not governed by this document and have no semantics in the
DATEX II specifications
6.2.4 If the “name” metaattribute of a DATEX II relation is empty, the default assumption is a name
constructed from the name of the connected memberEnd UML Class, where memberEnd.isComposite is
not set to “true”, with its first character turned to lower case
6.2.5 If the multiplicity of a DATEX II relations memberEnd is not explicitly specified, the default value
for Multiplicity.lower as well as for Multiplicity.upper is “1”
6.2.6 The “order” property of a DATEX II relation shall be a non-negative Integer and shall be different
from any other value of any other DATEX II relation that is connected to the same UML Class (i.e. all
associations adjacent to a composite class shall have distinct order values)
6.2.7 If two or more UML Associations connect the same UML Classes, they shall have non-empty
“definition” properties.
NOTE It is possible to provide further documentation using UML Core::Basic::Comment.
6.2.8 UML Associations may have a “qualifier” UML Property.
NOTE This property is deprecated. The intended effect can be achieved by the use of an optional “index”
attribute. The “schemaAttribute” UML Property is then set to “yes” for the “index” attribute.
6.3 Requirements on attributes
6.3.1 Figure 2depicts the stereotype “D2Attribute” defined for DATEX II attributes.

Figure 2 – Attributes
prEN 16156-1:2024 (E)
6.3.2 Attributes of DATEX II classes may have a “D2Attribute” stereotype assigned. Such attributes are
called “DATEX II attributes” for brevity in the rest of this document.
6.3.3 DATEX II models may contain attributes that have no “D2Attribute” stereotype or have other
stereotypes assigned. Attributes without “D2Attribute” stereotype assigned and other stereotypes on
attributes are not governed by this document, i.e. they have no semantics in the context of the DATEX II
specifications
6.3.4 The type of a DATEX II attribute shall be one of the following
— a UML DataType with stereotype “D2Codelist”, “D2Datatype” (Note that built-in UML types are not
allowed) or “ExternalType”,
— a UML Enumeration with stereotype “D2Enumeration” or
— a UML Class with any of the stereotypes depicted in clause 6.4.2.
Note Stereotypes “D2ModelRoot”, “D2Entity”, “D2EntityIdentifiable” and “D2EntityVersionedIdentifiable”
are not supposed be used as type of DATEX II attributes.
6.3.5 The “definition” property of a DATEX II attribute shall not be empty and shall contain a clear,
comprehensible and unambiguous definition of the modelled concept.
Note Further documentation can be provided using UML Core::Basic::Comment.
6.3.6 Any DATEX II attribute shall have a non-empty “order” property. This order shall be a non-
negative integer and all order values of such properties of the DATEX II attributes of the same DATEX II
class shall be unique within this class.
6.3.7 DATEX II attributes - as all UML attributes - inherit a “lower” and an “upper” attribute from UML
Core::Basic::MultiplicityElement. In case multiplicity attributes are not provided explicitly, a default
value of “1” is used
6.4 Requirements on classes
6.4.1 Figure 3 depicts stereotypes for classes that shall create a top-level element (“D2ModelRoot”), for
classes that represent domain entities (“D2Entity”, “D2EntityIdentifiable” and
“D2EntityVersionedIdentifiable”) and for non-entity classes, representing complex datatypes
(“D2Class”, “D2Identifiable” and “D2VersionedIdnetifiable”). Stereotypes ending “…Identifiable” have a
unique identity. Stereotypes ending “…VersionedIdentifiable” have an iterative life cycle. The last
stereotype “ExternalClass” is used to describe classes that are imported from other namespaces and can
thus be used in the model.
Figure 3 – Classes
6.4.2 DATEX II models may use UML Core::Basic::Class. Such classes may have a “D2ModelRoot”,
“D2Entity”, “D2EntityIdentifiable”, “D2EntityVersionedIdentifiable”, “D2Class”, “D2Identifiable”,
“D2VersionedIdentifiable” or a “ExternalClass” stereotype from the “UML Profile for DATEX II” assigned
to it. Classes with one of these stereotypes except “ExternalClass” assigned are called “DATEX II classes”
for brevity in the rest of this document.
6.4.3 DATEX II classes shall not have more than one stereotype “D2Class”, “D2ModelRoot”, “D2Entity”,
“D2EntityIdentifiable”, “D2EntityVersionedIdentifiable”, “D2Identifiable”, “D2VersionedIdentifiable” or
“ExternalClass” assigned
6.4.4 DATEX II models may contain UML Core::Basic::Classes that have none of the following
stereotypes “D2Class”, “D2ModelRoot”, “D2Entity”, “D2EntityIdentifiable”,
“D2EntityVersionedIdentifiable”, “D2Identifiable”, “D2VersionedIdentifiable” or a “ExternalClass”
assigned or they may have other stereotypes assigned. Classes without “D2Class”, “D2ModelRoot”,
“D2Entity”, “D2EntityIdentifiable”, “D2EntityVersionedIdentifiable”, “D2Identifiable”,
“D2VersionedIdentifiable” or a “ExternalClass” stereotype assigned and other stereotypes on classes are
not governed by this document, i.e. they have no semantics in the context of the DATEX II specifications
6.4.5 The “definition” property of a DATEX II class (except for “ExternalClass”) shall not be empty and
shall contain a clear, comprehensible and unambiguous definition of the class modelled
NOTE Further documentation can be provided using UML Core::Basic::Comment.
prEN 16156-1:2024 (E)
6.4.6 A UML model that claims conformity with this document shall contain at least one class with a
“D2ModelRoot” stereotype assigned to it.
NOTE If the model root is to be identifiable, the “D2ModelRoot” DATEX II class is declared abstract according
to 6.4.8 and then specialized by a class having either the DATEX II Stereotype “D2Identifiable” or
“D2VersionedIdentifiable”.
6.4.7 A “D2ModelRoot” DATEX II class that claims conformity with this document shall have the
“modelBaseVersion” property set to a value “4” and the “version” property set to “4.x”, where x is a non-
negative integer. They may have non-empty “extensionName” and “extensionVersion” properties if the
model is extended, making use of rules in clause 7.
6.4.8 DATEX II classes may be declared to be abstract, i.e. their “isAbstract” attribute may be set to
“true”
6.4.9 DATEX II classes (except “ExternalClass” classes) shall not have more than one superclass
6.4.10 “ExternalClass” classes shall have no superclass and no attributes and no associations. They only
serve as a reference to classes imported from outside the schema generated from the model
6.4.11 For all DATEX II classes, the following UML constructs shall be unique within each class
— UML Attributes “name”,
— “name” values of DATEX II relations connected to the class,
— “name” values of UML Classes connected via a DATEX II relation with an empty “name”, where
according to 6.2.4, this name is set to the “name” of their connected UML Class, with the first letter
turned to lower case.
6.5 Requirements on datatypes
6.5.1 Figure 4 depicts the stereotype “D2Datatype” used in general for defining DATEX II datatypes.
External datatypes may also be used by declaring them using the “ExternalType” stereotype. The
stereotype “D2Codelist” is introduced for datatypes that represent externally maintained lists of codes.
Figure 4 – Datatypes
6.5.2 DATEX II models may use UML Core::Basic::DataType. Such datatypes may have a “D2Codelist”,
“D2Datatype” or an “ExternalType” stereotype from the “UML Profile for DATEX II” assigned to it.
Datatypes with a “D2Codelist” or “D2Datatype” stereotype assigned are called “DATEX II datatypes” for
brevity in the rest of this document.
6.5.3 DATEX II datatypes shall not have more than one stereotype “D2Codelist”, “D2Datatype” or
“ExternalType” assigned
6.5.4 DATEX II models may contain UML Core::Basic::DataType that have no “D2Codelist”,
“D2Datatype” or “ExternalType” stereotype assigned or they may have other stereotypes assigned.
Datatypes without “D2Codelist”, “D2Datatype” or “ExternalType” stereotype assigned and other
stereotypes on datatypes are not governed by this document, i.e. they have no semantics in the context
of the DATEX II specifications
6.5.5 DATEX II datatypes with an “ExternalType” stereotype shall be defined inside packages that have
an “ExternalNamespace” stereotype assigned or that have an ancestor with that stereotype, i.e. either
they are defined directly inside an “ExternalNamespace” package or in packages defined in the package
hierarchy below such a package
6.5.6 The “definition” property of a “D2Datatype” DATEX II datatype shall not be empty and shall
contain a clear, comprehensible and unambiguous definition of the datatype modelled
NOTE Further documentation can be provided using UML Core::Basic::Comment.
6.5.7 The following list describes the set of predefined “D2Datatype” DATEX II datatypes that can be
declared in a DATEX II UML model. If they are used in the model, they shall be declared as a
“D2Datatype” with the corresponding name in the “Common” package according to 6.9.7. In this case,
the definition property does not have to be filled. The semantics are implicitly defined as follows:
— Base64Binary: Binary data in base 64 encoding, for example for image data.
prEN 16156-1:2024 (E)
— Boolean: Boolean has the value space required to support the mathematical concept of binary-
valued logic: {true, false}.
— Date: A combination of year, month and day integer-valued properties plus an optional
timezone property. It represents an interval of exactly one day, beginning on the first moment of the
day in the timezone, i.e. '00:00:00' up to but not including '24:00:00'.
— DateTime: A combination of integer-valued year, month, day, hour, minute properties, a decimal-
valued second property and a time zone property from which it is possible to determine the local
time, the equivalent UTC time and the time zone offset from UTC.
— Decimal: A decimal number whose value space is the set of numbers that can be obtained by
multiplying an integer by a non-positive power of ten, i.e. expressible as i × 10^-n where i and n are
integers and n > = 0.
— Double: A double precision number whose value space consists of the values m × 2^e, where m is
an integer whose absolute value is less than 2^53, and e is an integer between −1024 and 1023,
inclusive.
— Float: A floating point number whose value space consists of the values m × 2^e, where m is an
integer whose absolute value is less than 2^24, and e is an integer between −149 and 104, inclusive.
— Integer: An integer number whose value space is the set {-2147483648, −2147483647,
−2147483646, ., −2, −1, 0, 1, 2, ., 2147483645, 2147483646, 2147483647}.
— Language: A language datatype, identifies a specified language by an ISO 639-1 2-alpha code.
— LongString: A character string with no specified length limit, whose value space is the set of
finite-length sequences of characters. Every character has a corresponding Universal Character Set
code point (as defined in ISO/IEC 10646), which is an integer.
— NonNegativeInteger: An integer number whose value space is the set {0, 1, 2, ., 2147483645,
2147483646, 2147483647}.
— Reference: A reference to an identifiable managed object where the identifier is unique. It comprises
an identifier (e.g. UUID).
— String: A character string whose value space is the set of finite-length sequences of characters.
Every character has a corresponding Universal Character Set code point (as defined in
ISO/IEC 10646), which is an integer.
— Time: An instant of time that recurs every day. The value space of time is the space of time of
day values as defined in § 5.3 of [ISO 8601]. Specifically, it is a set of zero-duration daily time
instances.
— Url: A Uniform Resource Locator (URL) address comprising a compact string of characters for a
resource available on the Internet.
— VersionedReference: A reference to an identifiable version managed object where the
combination of the identifier and version is unique. It comprises an identifier (e.g. UUID) and a
version (NonNegativeInteger).
NOTE 1 Mappings to specific implementation platforms define a mapping for each of the above datatypes.
NOTE 2 The DATEX II datatype “VersionedReference” is used to refer to a class stereotyped as
“D2EntityVersionedIdentifiable” or “D2VersionedIdentifiable”, and the datatype “Reference” is used to refer to a
class stereotyped as “D2EntityIdentifiable” or “D2Identifiable”. This reference is visualized using a UML
Dependency [3] from the attribute typed as “Reference” or “VersionedReference” to the target class.
6.5.8 DATEX II datatypes or a specialization of these may have a non-empty “facets” property from a
datatype specific subset of the following list of facets:
— maxLength: , where x is the maximum allowed length of the
serialization of the attribute value expressed as a non-negative integer
— pattern: , where x is a regular expression according to Annex G of XML
Schema Definition Language (XSD) 1.1 Part 2: Datatypes matched against the serialization of the
attribute value
— mi
...