kSIST-TS FprCEN/TS 16157-15:2026

• Abstract:

  This document specifies a schema mapping using JavaScript Object Notation (JSON) as defined by JSON Schema (draft 2020-12) and subsequent versions. The schema mapping is the derived from the current UML model for DATEX II defined in 16157 Part 1. The schema mapping follows the JSON format defined by the Internet Engineering Task Force (IETF) in RFC 8259.

• Status: Not Published
• Public Enquiry End Date: 05-Aug-2026
• ICS: 03.220.20 - Road transport
• ICS: 35.240.60 - IT applications in transport
• Technical Committee: ITC - Information technology
• Current Stage: 5520 - Unique Acceptance Procedure (UAP) (Adopted Project)
• Start Date: 03-Jun-2026
• Due Date: 21-Oct-2026
• Completion Date: 15-Jul-2026
• Ref Project: CEN/TS 16157-15:2026 - Intelligent transport systems — DATEX II data exchange specifications for traffic management and information — Part 15: JSON Schema mapping

• Referred By: SIST-TS CEN/TS 17402:2020 - Intelligent transport systems - Urban ITS - Use of regional traffic standards in a mixed vendor environment
• Effective Date: 07-Oct-2026

kSIST-TS FprCEN/TS 16157-15:2026 is a CEN technical specification in the DATEX II family for intelligent transport systems. It specifies how Unified Modeling Language (UML) DATEX II models are mapped to JSON Schema and JSON for traffic management and information exchange, so implementers can generate and validate interoperable data representations.

What does kSIST-TS FprCEN/TS 16157-15:2026 specify?

kSIST-TS FprCEN/TS 16157-15:2026 specifies a schema mapping from DATEX II UML models into JavaScript Object Notation (JSON) using JSON Schema draft 2020-12 and later versions, with JSON syntax aligned to RFC 8259. In practice, this part tells tool builders how to turn the DATEX II model into machine-readable schema files for exchange, validation, and implementation.

The document is organized into clauses on scope, normative references, terms and definitions, symbols and abbreviations, overall document structure and namespaces, datatype mapping, enumeration and literal mapping, class mapping, identifiable and versioned identifiable classes, the model root, and Level B extension mapping, followed by a bibliography.

What are the key requirements of kSIST-TS FprCEN/TS 16157-15:2026?

• Clause 5 sets the file structure and namespace rules. Each «D2Namespace» becomes its own JSON Schema file, and cross-namespace links use $ref references. This matters because implementations can split large DATEX II models into predictable files and still keep references valid across packages.

• Clause 5 also defines naming and extension handling. File names follow the DATEXII model-and-namespace pattern, Level B extensions stay with the concepts they extend, and Level C extensions use a distinct schema file name. In practice, this gives a clear rule for versioned model distribution and prevents mixed schemas from being confused with one another.

• Clause 6 maps «D2Datatype» to JSON Schema. Most datatypes keep the UML name, with UML tagged values carried into JSON Schema properties such as description, and datatype facets mapped into JSON constraints. This is what turns model-level datatype rules into validation rules that software can enforce.

• Clause 6.2 describes how UML datatype attributes become JSON types. Primitive UML datatype settings are mapped into JSON string, number, integer, boolean, date, time, and encoded-string forms, while schemaTypeInclude covers structured cases such as multilingual strings and references. For a reader, this is the part that determines whether a field becomes a plain scalar, an array, or a nested object.

• Clause 7 handles «D2Enumeration» and «D2Literal». Enumeration literals are emitted in UML order, and every enumeration gets the reserved extendedG literal for backward-compatible extension. When an enumeration is used as an attribute, the schema uses a wrapper object with an extendedValueG option, which lets implementations carry either a known literal or an extended value.

• Clause 8 maps «D2Class» structures. The document distinguishes classes without superclasses, classes with superclasses, and classes that act as superclasses, and it also adds ExtensionTypeG support to all classes. In practice, this is the core of how DATEX II object structures, compositions, and inheritance appear in JSON Schema.

• Clause 8.3 controls attribute and relation ordering. Attributes come first, then compositions, then the extension element, and multi-valued properties use arrays with bounds taken from UML multiplicities when they are present. That matters because generated schema files stay stable and reflect the UML model structure in a consistent order.

• Clause 9 defines «D2Identifiable» and «D2VersionedIdentifiable». These classes require idG, and versioned identifiables also require versionG; references to them use Reference or VersionedReference depending on the target class. This gives a clear, data-model-level way to identify shared objects and distinguish versions when the model requires it.

• Clause 10 maps «D2ModelRoot» to top-level schema elements. The root class becomes a top-level declaration that points to the generated root wrapper or class schema. For implementers, this is the entry point for a complete DATEX II payload schema.

• Clause 11 defines Level B extension handling across model boundaries. When a superclass is in the core model and subclasses are introduced by a Level B extension, the schema uses a specific extension type that collects the new subclasses or literals. This is important for backward-compatible evolution, because it keeps older validators working while allowing new model content.

What terms does kSIST-TS FprCEN/TS 16157-15:2026 define?

• Unified Modeling Language (UML) is the source modeling language used for DATEX II classes, attributes, relations, and datatypes.
• JavaScript Object Notation (JSON) is the target data-interchange format into which the DATEX II model is mapped.
• JSON Schema is the schema language used to describe the generated JSON structure and validation rules.
• Lower camel case (LCC) means a naming style with a lowercase first letter, used for several generated JSON names.
• Upper camel case (UCC) means a naming style with an uppercase first letter, used for wrapper and type names.
• D2Class is the UML stereotype for model classes that are mapped into JSON Schema object definitions.
• D2Identifiable and D2VersionedIdentifiable are stereotypes for classes that carry required identity, and optionally version, properties.
• Level B extension is a backward-compatible extension mechanism used when new model content is added across the DATEX II model boundary.

Who uses kSIST-TS FprCEN/TS 16157-15:2026?

kSIST-TS FprCEN/TS 16157-15:2026 is used by DATEX II modelers, software vendors, system integrators, and tool developers who build traffic management and information exchange systems. It is also relevant to road administrations, infrastructure providers, service providers, and transport IT teams that need to generate schemas, validate payloads, or maintain namespace and extension rules across DATEX II implementations.

In practice, these users apply it when they:

• generate JSON Schema from UML models,
• implement DATEX II interfaces and payload validation,
• manage model extensions without breaking older data exchanges,
• structure schema files and cross-file references for deployment.

What changed in kSIST-TS FprCEN/TS 16157-15:2026 from the previous edition?

kSIST-TS FprCEN/TS 16157-15:2026 supersedes CEN/TS 17466.

Which standards are used with kSIST-TS FprCEN/TS 16157-15:2026?

• EN 16157-1:2018 provides the common context and framework for DATEX II and is the model basis used by this part for the JSON Schema mapping.
• RFC 8259 defines the JSON data interchange format that this document follows for the generated schemas.
• JSON Schema draft 2020-12 is the schema vocabulary used for the mapping rules and generated schema structure.

What does the kSIST-TS FprCEN/TS 16157-15:2026 document contain?

The document contains mapping rules, not implementation code. Clause 6 includes datatype mapping tables, including how UML datatypes and datatype includes are represented in JSON Schema. Clause 7 defines enumeration handling, the reserved extendedG literal, and the wrapper form used for enumeration attributes.

Clause 8 contains the class-mapping patterns, including general class structure, inheritance handling, property ordering, and extension support. Clause 9 gives the identity and version reference structures for identifiable classes, and clause 10 gives the root-element structure for schema entry points. Clause 11 shows how Level B extensions change the generated schema for classes and enumerations.

SLOVENSKI STANDARD
01-julij-2026
Inteligentni transportni sistemi - Specifikacije za izmenjavo podatkov DATEX II pri
upravljanju prometa in informiranju - 15. del: Povezovanje s shemo JSON
Intelligent transport systems — DATEX II data exchange specifications for traffic
management and information — Part 15: JSON Schema mapping
Intelligente Verkehrssysteme - DATEX II Datenaustauschspezifikation für
Verkehrsmanagement und Verkehrsinformation - Teil 15: Abbildung des JSON-Schema
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 15 : Mappage de Schéma JSON
Ta slovenski standard je istoveten z: FprCEN/TS 16157-15
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.

FINAL DRAFT
TECHNICAL SPECIFICATION
FprCEN/TS 16157-15
SPÉCIFICATION TECHNIQUE
TECHNISCHE SPEZIFIKATION
May 2026
ICS Will supersede
English Version
Intelligent transport systems - DATEX II data exchange
specifications for traffic management and information -
Part 15: JSON Schema mapping
Systèmes de transport intelligents - Spécifications Intelligente Verkehrssysteme - DATEX II
Datex II d'échange de données pour la gestion du trafic Datenaustauschspezifikation für Verkehrsmanagement
et l'information routière - Partie 15 : Mappage de und Verkehrsinformation - Teil 15: Abbildung des
Schéma JSON JSON-Schema
This draft Technical Specification is submitted to CEN members for Vote. It has been drawn up by the Technical Committee
CEN/TC 278.
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 Technical Specification. It is distributed for review and comments. It is subject to change
without notice and shall not be referred to as a Technical Specification.

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
© 2026 CEN All rights of exploitation in any form and by any means reserved Ref. No. FprCEN/TS 16157-15:2026 E
worldwide for CEN national Members.

FprCEN/TS 16157-15:2026 (E)
Contents Page
European foreword . 3
Introduction . 4
1 Scope . 5
2 Normative references . 5
3 Terms and definitions . 5
4 Symbols and abbreviations . 5
5 Overall document structure and namespaces . 5
5.1 General. 5
5.2 File naming . 6
5.3 Cross-file references . 6
5.4 Extensions and namespace rules . 6
6 Mapping of «D2Datatype» . 7
6.1 General. 7
6.2 Mapping of UML Datatypes to JSON . 7
7 Mapping of «D2Enumeration» and «D2Literal» . 11
7.1 «D2Enumeration» . 11
7.2 «D2Literal» . 11
7.3 «D2Enumeration» wrapper . 11
8 Mapping of «D2Class» . 12
8.1 General. 12
8.2 Mapping of ExtensionType . 12
8.3 «D2Class» classes without superclass . 12
8.4 «D2Class» classes with superclass . 15
8.5 «D2Class» class which is a superclass . 15
9 Mapping of «D2Identifiable» and «D2VersionedIdentifiable» classes . 16
9.1 General. 16
9.2 «D2Identifiable» . 16
9.3 «D2VersionedIdentifiable» . 16
9.4 References to «D2Identifiable» and «D2VersionedIdentifiable» . 16
10 Mapping of «D2ModelRoot» . 18
10.1 «D2ModelRoot» . 18
11 Mapping of Level B extension . 18
11.1 General. 18
11.2 Extension mapping for Classes . 19
11.3 Extension mapping for Enumerations. 20
Bibliography . 21

FprCEN/TS 16157-15:2026 (E)
European foreword
This document (FprCEN/TS 16157-15:2026) 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 Vote as TS.
This document will supersede CEN/TS 17466.
The CEN 16157 series consist of several parts under the general title “Intelligent transport systems —
DATEX II data exchange specifications for traffic management and information”. Other parts may be
developed in the future.
A list of all parts in a series can be found on the CEN website: www.cencenelec.eu.
As a user of this document, attention is drawn to the resources of www.datex2.eu. This web site contains
related software tools and software resources that aid the implementation of EN 16157 DATEX II.
FprCEN/TS 16157-15:2026 (E)
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
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 for 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 road traffic management and related services for 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 their systems, as well as in coherent 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.
Attention is drawn to the possibility that some of the elements of this document may be the subject of
patent rights. CEN shall not be held responsible for identifying any or all such patent rights.
This European Standard includes the framework and context for exchanges, the modelling approach, data
content, data structure and relationships.
This European Standard supports a methodology that is extensible.
Part 15 of the CEN/TS 16157 series (this Technical Specification) specifies the mapping from UML models
into a JSON Schema representation, in compliance with CEN/EN 16157-1, which defines the overall
context and framework for such mappings, including the corresponding XML Schema representation.
FprCEN/TS 16157-15:2026 (E)
1 Scope
The CEN 16157 multipart standard specifies and defines component aspects supporting the shared use
of data and information in the field of traffic and travel. The component aspects include the modelling
approach, the data content, the data structure and relationships and the communications specification.
This document defines a mapping from UML models, compliant with EN 16157-1, into JavaScript Object
Notation (JSON) using JSON Schema as specified in draft 2020-12 and subsequent versions.
The schema mapping conforms to the JSON format defined by the Internet Engineering Task Force (IETF)
in RFC 8259.
In the context of describing generation of schema, this refers to the webtool made available as part of the
CEN 16157 multipart standard, which can generate the JSON schema mapping specified in this document.
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.
EN 16157-1:2018, Intelligent transport systems - DATEX II data exchange specifications for traffic
management and information - Part 1: Context and framework
3 Terms and definitions
There are no terms and definitions listed in this document.
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/
4 Symbols and abbreviations
UML Unified Modeling Language
JSON JavaScript Object Notation
LCC lower camel case
UCC upper camel case
URI Uniform Resource Identifier
URL Uniform Resource Locator
5 Overall document structure and namespaces
5.1 General
The mapping rules described in this document define the structure of types, properties, and elements
derived from the UML model. In order to provide a usable implementation format these types, properties
and elements are organised into JSON Schema definition files. Each file corresponds to one
«D2Namespace» and contains the complete set of class, enumeration, and reference definitions belonging
to that package.
FprCEN/TS 16157-15:2026 (E)
The "title" properties are optional. The "description" properties are intended solely for documentation
purposes and shall only be included if a schema that includes definitions and descriptions is being
generated, with exception on necessary information to the programmer, where description will be
generated.
The whole set of type and element definitions provided in the following sections are wrapped into
multiple JSON schema definition files, each with the following JSON structure:
{
"$schema": "https://json-schema.org/draft/2020-12/schema",
"$defs": {
Definitions of classes, enumerations, wrappers and references are
inserted here
}
…other top-level members if applicable
}
5.2 File naming
Each «D2Namespace» in the source model shall be mapped to its own JSON Schema definition file using:
DATEXII__.json
where:
• is taken from the corresponding attribute on the class stereotyped as
«D2ModelRoot».
• is the name of the package stereotyped as «D2Namespace».
5.3 Cross-file references
Where one «D2Namespace»uses constructs from another «D2Namespace»then the schema within the
using namespace shall use a JSON Schema $ref construct referencing a schema in the schema file for the
used namespace, in the following pattern:
"": {
"$ref":
".json#/$defs/"
}
5.4 Extensions and namespace rules
• Level B (backward-compatible) extensions. If a model contains Level B extension classes, the
JSON Schema constructs for those extension classes shall be placed in the JSON Schema for the
concepts they extend.
• Level C (non-backward-compatible) extensions. If an extended model is not backward
compatible, a distinct schema filename shall be used to clearly distinguish the Level C schema from
the Level A schema. The schema filename shall be used to reference other schema using the keyword
$ref.
NOTE The tool provided to generate schemas will prefix the schema filenames, and subsequently use this
prefixed filename for reference other schemas using the keyword $ref.
FprCEN/TS 16157-15:2026 (E)
6 Mapping of «D2Datatype»
6.1 General
In this document UML datatypes classified as «D2Datatype» are, in principle, mapped to JSON Schema
definitions bearing the same name as the UML datatype.
Exceptions to this mapping — that is, instances where a «D2Datatype» is mapped differently — are
documented in the following sections.
Additionally, the value of the "definition" tagged value in UML is mapped to the description property in
JSON Schema. The general structure is as follows:
: {
"title": "",
"description": "",
"type": "RestrictionBase"
}
The value of "type" (referred to as "RestrictionBase" in pseudocode) is determined by the following
algorithm:
1. If the assigned «D2Datatype» stereotype has a non-empty schemaType property (see EN 16157-
1:2018, Part 1: Context and framework, Section 6.2.4), then this value is mapped according to the
Mapping of Datatypes table (see below).
2. If both schemaType and schemaTypeInclude properties of the «D2Datatype» stereotype are empty,
then the value of "type" is replaced with a $ref pointing to the supertype definition:
"$ref": "#/$defs/"
6.2 Mapping of UML Datatypes to JSON
6.2.1 schemaType attribute
The ollowing table shows mapping of schemaType attribute in UML to JSON type. If no mapping is found,
string shall be used as default mapping. Where a phrase in angle brackets ends with
“FromFacetsInUMLModel”, the part before that suffix is the name from tag in the UML ‘facets’ tagged
value.
NOTE Derived types of types defined in Table 1 can also contain definition of facets.
Table 1 — Mapping table datatypes, schemaType
schemaType JSON
base64Binary “type:”:”string”
“contentEncoding”:”base64”
“pattern”:”^[A-Za-z0-9+/]+={0,2}$”
boolean "type": "boolean"
date "type": "string"
“format”: “date”
dateTime "type": "string"
"format": "date-time"
FprCEN/TS 16157-15:2026 (E)
decimal "type": "number"
(Optional facets)
“minimum”:
“maximum”:
double "type": "number"
(Optional facets)
“minimum”:
“maximum”:
float "type": "number"
(Optional facets)
“minimum”:
“maximum”:
int "type": "integer"
(Optional facets)
“minimum”:
“maximum”:
integer "type": "integer"
(Optional facets) minInclusive and maxInclusive
“minimum”:
“maximum”:
language “type:”:”string”
“pattern”: "^[a-z]{2}$"
negativeInteger "type": "integer", " exclusiveMaximum": 0
positiveInteger "type": "integer", "exclusiveMinimum ": 0
nonNegativeInteger "type": "integer", "minimum": 0
string "type": "string"
(Optional facets)
“maximumLength”:
“pattern”:”
time "type": "string"
“format”: “time”
url "type": "string"
FprCEN/TS 16157-15:2026 (E)
6.2.2 schemaTypeInclude attribute
The following table shows mapping of schemaTypeInclude attribute in UML to JSON type.
Table 2 — Mapping table datatypes, schemaTypeInclude
schemaTypeInclude JSON
MultiLingualString {
MultilingualString: {
"title": "MultilingualString",
"description": "",
"type": "object",
"additionalProperties": false,
"properties": {
"values": {
"type": "array",
"items": {
"$ref":
"#/$defs/MultiLingualStringValue"
}
}
}
},
"MultiLingualStringValue": {
"title": "MultiLingualStringValue",
"description": "",
"type": "object",
"additionalProperties": false,
"properties": {
"lang": {
"type": "string",
"pattern": "^[a-z]{2}$"
},
"value": {
"type": "string"
}
},
"required": [
"lang",
"value"
]
}
}
----------------
...