ISO 21219-4:2019

Intelligent transport systems - Traffic and travel information (TTI) via transport protocol experts group, generation 2 (TPEG2) - Part 4: UML to XML conversion rules

This document specifies the rules for converting TPEG application UML models to the tpegML format description. It contains the XML format definition of the abstract data types defined in ISO 21219-2. Rules for converting compound data types are also defined.

Systèmes intelligents de transport — Informations sur le trafic et le tourisme via le groupe expert du protocole de transport, génération 2 (TPEG2) — Partie 4: Règles de conversion d'UML en XML

General Information

• Status: Published
• Publication Date: 23-Jul-2019
• ICS: 03.220.01 - Transport in general
• ICS: 35.240.60 - IT applications in transport
• Technical Committee: ISO/TC 204 - Intelligent transport systems
• Drafting Committee: ISO/TC 204/WG 10 - Traveller information systems
• Current Stage: 9093 - International Standard confirmed
• Start Date: 06-Jun-2025
• Completion Date: 13-Dec-2025

Relations

• Revises: ISO/TS 21219-4:2015 - Intelligent transport systems - Traffic and travel information (TTI) via transport protocol experts group, generation 2 (TPEG2) - Part 4: UML to XML conversion rules
• Effective Date: 23-Apr-2020

Overview

ISO 21219-4:2019 - Intelligent transport systems (ITS): Traffic and travel information (TTI) via TPEG2 - Part 4 defines the UML to XML conversion rules for TPEG Generation 2 (TPEG2). The standard specifies how to convert TPEG application UML models into the tpegML format description, provides the XML (XSD) format definition for the abstract data types defined in ISO 21219-2, and sets out rules for converting compound data types. ISO 21219-4:2019 is intended as the normative basis for producing a tpegML annex in TPEG2 application and toolkit specifications.

Key technical topics and requirements

• tpegML schema definition: Guidance on namespace naming (http://www.tisa.org/TPEG/TPEGDataTypes_[MajorVersion]_[MinorVersion]), default/target namespace usage and schema import rules.
• XML Schema (XSD) settings: Recommendations that XSD elements and attributes be qualified, with elementFormDefault and attributeFormDefault set to “qualified”.
• XML format description structure: A required annex naming convention ([Specification Identification], tpegML representation) with subclauses for Introduction and Application data type definition.
• Abstract data types and ranges: XML definitions for the abstract data types from ISO 21219-2 and explicit handling of XML data type ranges.
• Tables and enumerations: Rules for mapping TPEG standard tables, application tables (<> stereotypes) and switching tables into XML.
• Stereotype handling: Conversion rules for <> types, including TPEG application externals and non-TISA external references (XML schema or binary).
• Compound data types: Detailed conversion rules for classes, root elements, attributes, and specializations/abstract classes (see clauses such as 5.10 and its subrules).
• Normative references: Alignment with ISO 21219-2 (UML modelling rules), ISO 21219-5 (service framework), and ISO 8601 (date/time representation).

Practical applications and users

ISO 21219-4:2019 is primarily used to enable reliable, interoperable XML representations of TPEG2 traffic and travel information. Typical users include:

• ITS application developers and system integrators creating TPEG2 content pipelines and services.
• Data modelers and UML architects converting UML models into validated tpegML schemas.
• Tool and platform vendors implementing automated UML→tpegML conversion, schema generation and validation.
• Service providers and broadcasters publishing traffic and travel information in XML-based exchange formats.
• Standards and compliance teams ensuring TPEG2 artifacts conform to the required schema, namespaces and conversion rules.

Benefits include improved interoperability, consistent schema generation, easier validation of TTI content, and support for automated toolchains that convert UML models (XMI) into reusable tpegML XSDs.

Related standards

• ISO 21219-2 - TPEG2 UML modelling rules (abstract data type definitions referenced by this part)
• ISO 21219-5 - TPEG2 Service Framework (tpegML schema import guidance)
• ISO 8601 series - Date and time representations used in XML data types

Keywords: ISO 21219-4:2019, TPEG2, UML to XML conversion, tpegML, intelligent transport systems, traffic and travel information, XML schema, XSD, abstract data types.

Standards Content (Sample)

INTERNATIONAL ISO
STANDARD 21219-4
First edition
2019-07
Intelligent transport systems —
Traffic and travel information (TTI)
via transport protocol experts group,
generation 2 (TPEG2) —
Part 4:
UML to XML conversion rules
Systèmes intelligents de transport — Informations sur le trafic et le
tourisme via le groupe expert du protocole de transport, génération 2
(TPEG2) —
Partie 4: Règles de conversion d'UML en XML
Reference number
©
ISO 2019
© ISO 2019
All rights reserved. Unless otherwise specified, or required in the context of its implementation, no part of this publication may
be reproduced or utilized otherwise in any form or by any means, electronic or mechanical, including photocopying, or posting
on the internet or an intranet, without prior written permission. Permission can be requested from either ISO at the address
below or ISO’s member body in the country of the requester.
ISO copyright office
CP 401 • Ch. de Blandonnet 8
CH-1214 Vernier, Geneva
Phone: [phone]
Fax: [phone]
Email: [e-mail]
Website: www.iso.org
Published in Switzerland
ii © ISO 2019 – All rights reserved

Contents Page
Foreword .iv
Introduction .v
1 Scope . 1
2 Normative references . 1
3 Terms and definitions . 1
4 Abbreviated terms . 2
5 Rules for UML to XML format description conversion . 2
5.1 Definition of XML format description . 2
5.2 The tpegML schema definition . 2
5.3 The tpegML xml file definition . 3
5.4 XML data type ranges . 3
5.5 Abstract data types . 4
5.6 TPEG standard tables . 5
5.7 Application tables (stereotype <>) . 5
5.8 Switching tables . 6
5.9 Stereotype <> . 7
5.9.1 TPEG application <> type . 7
5.9.2 Non-TISA <> XML schema . 8
5.9.3 Non-TISA <> binary type . 9
5.10 Compound data types .10
5.10.1 Rule 1 — Classes .10
5.10.2 Rule 2 — Root element .11
5.10.3 Rule 3 — Attributes .11
5.10.4 Rule 4 — Specialisations/Abstract classes .13
5.11 Example .16
Annex A (normative) TPEG Data Types schema definition .23
Bibliography .40
Foreword
ISO (the International Organization for Standardization) is a worldwide federation of national standards
bodies (ISO member bodies). The work of preparing International Standards is normally carried out
through ISO technical committees. Each member body interested in a subject for which a technical
committee has been established has the right to be represented on that committee. International
organizations, governmental and non-governmental, in liaison with ISO, also take part in the work.
ISO collaborates closely with the International Electrotechnical Commission (IEC) on all matters of
electrotechnical standardization.
The procedures used to develop this document and those intended for its further maintenance are
described in the ISO/IEC Directives, Part 1. In particular, the different approval criteria needed for the
different types of ISO documents should be noted. This document was drafted in accordance with the
editorial rules of the ISO/IEC Directives, Part 2 (see www .iso .org/directives).
Attention is drawn to the possibility that some of the elements of this document may be the subject of
patent rights. ISO shall not be held responsible for identifying any or all such patent rights. Details of
any patent rights identified during the development of the document will be in the Introduction and/or
on the ISO list of patent declarations received (see www .iso .org/patents).
Any trade name used in this document is information given for the convenience of users and does not
constitute an endorsement.
For an explanation of the voluntary nature of standards, the meaning of ISO specific terms and
expressions related to conformity assessment, as well as information about ISO's adherence to the
World Trade Organization (WTO) principles in the Technical Barriers to Trade (TBT) see www .iso
.org/iso/foreword .html.
This document was prepared by Technical Committee ISO/TC 204, Intelligent transport systems.
This first edition cancels and replaces ISO/TS 21219-4:2015 which has been technically revised.
A list of all parts in the ISO 21219 series can be found on the ISO website.
Any feedback or questions on this document should be directed to the user’s national standards body. A
complete listing of these bodies can be found at www .iso .org/members .html.
iv © ISO 2019 – All rights reserved

Introduction
History
TPEG technology was originally proposed by the European Broadcasting Union (EBU) Broadcast
Management Committee, who established the B/TPEG project group in the autumn of 1997 with a brief
to develop, as soon as possible, a new protocol for broadcasting traffic and travel-related information
in the multimedia environment. TPEG technology, its applications and service features were designed
to enable travel-related messages to be coded, decoded, filtered and understood by humans (visually
and/or audibly in the user’s language) and by agent systems. Originally, a byte-oriented data stream
format, which may be carried on almost any digital bearer with an appropriate adaptation layer,
was developed. Hierarchically structured TPEG messages from service providers to end-users were
designed to transfer information from the service provider database to an end-user’s equipment.
One year later, in December 1998, the B/TPEG group produced its first EBU specifications. Two
documents were released. Part 2 (TPEG-SSF, which became ISO/TS 18234-2) described the syntax,
semantics and framing structure, which was used for all TPEG applications. Meanwhile, Part 4 (TPEG-
RTM, which became ISO/TS 18234-4) described the first application for road traffic messages.
Subsequently, in March 1999, CEN/TC 278, in conjunction with ISO/TC 204, established a group
comprising members of the former EBU B/TPEG and this working group continued development work.
Further parts were developed to make the initial set of four parts, enabling the implementation of a
consistent service. Part 3 (TPEG-SNI, ISO/TS 18234-3) described the service and network information
application used by all service implementations to ensure appropriate referencing from one service
source to another.
Part 1 (TPEG-INV, ISO/TS 18234-1) completed the series by describing the other parts and their
relationship; it also contained the application IDs used within the other parts. Additionally, Part 5, the
public transport information application (TPEG-PTI, ISO/TS 18234-5), was developed. The so-called
TPEG-LOC location referencing method, which enabled both map-based TPEG-decoders and non-map-
based ones to deliver either map-based location referencing or human readable text information,
was issued as ISO/TS 18234-6 to be used in association with the other applications of parts of the
ISO/TS 18234 series to provide location referencing.
The ISO/TS 18234 series has become known as TPEG Generation 1.
TPEG Generation 2
When the Traveller Information Services Association (TISA), derived from former forums, was
inaugurated in December 2007, TPEG development was taken over by TISA and continued in the TPEG
applications working group.
It was about this time that the (then) new Unified Modelling Language (UML) was seen as having major
advantages for the development of new TPEG applications in communities who would not necessarily
have binary physical format skills required to extend the original TPEG TS work. It was also realized
that the XML format for TPEG described within the ISO/TS 24530 series (now superseded) had a greater
significance than previously foreseen, especially in the content-generation segment and that keeping
two physical formats in synchronism, in different standards series, would be rather difficult.
As a result, TISA set about the development of a new TPEG structure that would be UML-based. This has
subsequently become known as TPEG Generation 2.
TPEG2 is embodied in the ISO/TS 21219 series and it comprises many parts that cover introduction,
rules, toolkit and application components. TPEG2 is built around UML modelling and has a core of
rules that contain the modelling strategy covered in ISO 21219-2, ISO 21219-3 and ISO 21219-4 and
the conversion to two current physical formats: binary and XML; others could be added in the future.
TISA uses an automated tool to convert from the agreed UML model XMI file directly into an MS Word
document file, to minimize drafting errors, that forms the annex for each physical format.
TPEG2 has a three-container conceptual structure: message management (ISO 21219-6), application
(several parts) and location referencing (ISO/TS 21219-7). This structure has flexible capability and
can accommodate many differing use cases that have been proposed within the TTI sector and wider
for hierarchical message content.
TPEG2 also has many location referencing options as required by the service provider community, any
of which may be delivered by vectoring data included in the location referencing container.
The following classification provides a helpful grouping of the different TPEG2 parts according to their
intended purpose. Note that the list below may be incomplete, e.g. new TPEG2 parts may be introduced
after publication of this document.
— Toolkit parts: TPEG2-INV (ISO/TS 21219-1), TPEG2-UML (ISO 21219-2), TPEG2-UBCR (ISO 21219-3),
TPEG2-UXCR (ISO 21219-4), TPEG2-SFW (ISO 21219-5), TPEG2-MMC (ISO 21219-6), TPEG2-LRC
(ISO/TS 21219-7).
— Special applications: TPEG2-SNI (ISO/TS 21219-9), TPEG2-CAI (ISO/TS 21219-10), TPEG2-LTE
(ISO/TS 21219-24).
— Location referencing: TPEG2-OLR (ISO/TS 21219-22), TPEG2-GLR (ISO/TS 21219-21), TPEG2-TLR
(ISO 17572-2), TPEG2-DLR (ISO 17572-3).
— Applications: TPEG2-PKI (ISO/TS 21219-14), TPEG2-TEC (ISO/TS 21219-15), TPEG2-FPI
(ISO/TS 21219-16), TPEG2-TFP (ISO 21219-18), TPEG2-WEA (ISO/TS 21219-19), TPEG2-RMR
(ISO/TS 21219-23), TPEG2-EMI (ISO/TS 21219-25), TPEG2-VLI (ISO/TS 21219-26).
TPEG2 has been developed to be broadly (but not totally) backward compatible with TPEG1 to assist
in transitions from earlier implementations, while not hindering the TPEG2 innovative approach and
being able to support many new features, such as dealing with applications having both long-term,
unchanging content and highly dynamic content, such as parking information.
This document is based on the TISA specification technical/editorial version reference: SP14004.
vi © ISO 2019 – All rights reserved

INTERNATIONAL STANDARD ISO 21219-4:2019(E)
Intelligent transport systems — Traffic and travel
information (TTI) via transport protocol experts group,
generation 2 (TPEG2) —
Part 4:
UML to XML conversion rules
1 Scope
This document specifies the rules for converting TPEG application UML models to the tpegML format
description. It contains the XML format definition of the abstract data types defined in ISO 21219-2.
Rules for converting compound data types are also defined.
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 8601 (series), Data and time — Representations for information interchange
ISO 21219-2, Intelligent transport systems — Traffic and travel information (TTI) via transport protocol
experts group, generation 2 (TPEG2) — Part 2: UML modelling rules
ISO 21219-5, Intelligent transport systems — Traffic and travel information (TTI) via transport protocol
experts group, generation 2 (TPEG2) — Part 5: Service framework (TPEG2-SWF)
3 Terms and definitions
For the purposes of this document, the terms and definitions given in ISO 21219-2 and the following apply.
ISO and IEC maintain terminological databases for use in standardization at the following addresses:
— ISO Online browsing platform: available at https: //www .iso .org/obp
— IEC Electropedia: available at http: //www .electropedia .org/
3.1
Specification Identification
string that uniquely identifies a certain version of a certain TPEG application or toolkit
EXAMPLE The TPEG Traffic Event Compact application, version 2.0 is identified by the Specification
Identification string “TEC_2_0”.
3.2
Specification Name
string that verbosely describes a certain TPEG application or toolkit
EXAMPLE The TPEG Traffic Event Compact application, “TrafficEventCompact”.
3.3
application namespace prefix
string of the lower case application/toolkit abbreviation as defined in the UML tagged value
“ApplicationAbbreviation”
4 Abbreviated terms
The abbreviated terms in ISO 21219-2 and the following apply.
XML eXtensible Markup Language
XSD XML Schema Definition
UML Unified Modelling Language
app a placeholder for an application namespace prefix to create examples in this document.
It is replaced by the lowercase application abbreviation of the relevant TPEG application.
5 Rules for UML to XML format description conversion
5.1 Definition of XML format description
The xml format description of TPEG applications is included in application and toolkit specifications as
a normative annex. This annex shall be named according to the following scheme:
[Specification Identification], tpegML representation
The annex shall have two subclauses: Introduction and Application data type definition. The content of
these subclauses is subject to the specifications in this clause.
The Introduction shall use a similar formulation as in the following:
This clause defines the tpegML format representation of the [specification or toolkit name] message
components, datastructures and its attributes. For further descriptions of these objects see the
related clauses [reference to clauses] in this document.
The application data type definition shall follow the rules that are specified in 5.10.
5.2 The tpegML schema definition
The xml format of TPEG applications will be described according to „XML Schema Definition“. To use a
tpegML schemas, the tag shall contain the definition for the namespace http: //www .tisa
.org/TPEG/TPEGDataTypes _[MajorVersion] _[MinorVersion], where the version numbers are the release
versions of the specification as released by TISA (while the version numbers may be are exemplary in
the subsequent tables).
Each tpegML schema shall contain at least the following definitions:
— Default namespace shall be set to the tpegML schema itself;
— Target namespace shall be set to the tpegML schema itself;
— The XSD elements shall be qualified;
— The elementFormDefault should be set to “qualified”;
— The attributesFormDefault should be set to “qualified”;
— The prefix and namespace of service framework tpegML schema shall be declared and imported
(see ISO 21219-5).
2 © ISO 2019 – All rights reserved

The path to the tpegML schema shall have following syntax:
“http: //www .tisa .org/TPEG/[SpecificationIdentification]”
with
[Specification Identification] = [upper case Application or Toolkit abbreviation]_[Major version number]_
[Minor version number]
The schemaLocation of all imported schemas shall be changed to local path for the validating process.
Accordingly, the resulting start tag of tpegML schema shall be:
xmlns: xs = ”http: //www .w3 .org/2001/XMLSchema”
targetNamespace=”http: //www .tisa .org/TPEG/[Specification Identification]”
xmlns: sfw = ”http: //www .tisa .org/TPEG/ServiceFramework _0 _0
elementFormDefault=”qualified”
attributeFormDefault=”qualified”>
schemaLocation=”http: //www .tisa .org/TPEG/SFW _0 _0 .xsd” />
…

5.3 The tpegML xml file definition
For the xml file defined by the tpegML schema definition in 5.2, the following shall apply:
— No default name space shall be used. All elements and attributes shall have namespace prefixes.
This enhances readability and prevents attribute naming problems with imported xsds.
— The name space of the applications and toolkits should be defined by using the application
namespace prefix.
— The document encoding shall be “UTF-8”.
Accordingly, the xml document will look similar to this example (“app” and “APP” used as placeholders):

xmlns: app = ”http: //www .tisa .org/TPEG/APP _0 _0”
xmlns: mmc = http: //www .tisa .org/TPEG/MMC _0 _0”
xmlns: tdt = ”http: //www .tisa .org/TPEG/TPEGDataTypes _0 _0”
xmlns: sfw = ”http: //www .tisa .org/TPEG/SFW _0 _0”
…

The xml files defined by this document can hold one application message only (UML class tagged as
“ApplicationRoot”). To encode several TPEG application messages, an xml framing shall be applied, for
example as defined in ISO 21219-5.
5.4 XML data type ranges
XML data type Range
xs: byte −128 . 127
XML data type Range
xs: short −32768 . 32767
xs: int −2147483648 . 2147483647
xs: integer −infinite . infinite
xs: unsignedByte 0 . 255
xs: unsignedShort 0 . 655535
xs: unsignedInt 0 . 4294967295
xs: float m * 2^e, where −2^24 5.5 Abstract data types
The UML attributes of abstract data types shall be converted to the XSD local elements using the “TPEG
Data Types” schema [see Annex A]. The “TPEG Data Type” schema contains the XSD definition for all TPEG
abstract data types. To use “TPEG Data Types” schema, the tag shall contain the definition
for the namespace http: //www .tisa .org/TPEG/TPEGDataTypes _[MajorVersion] _[MinorVersion], where
the version numbers are the release versions of the specification as released by TISA. Additionally, the
schema shall be imported by adding the element (see XSD example). The definition of the
“schemaLocation” attribute within the element can differ from the defined namespace
URI but it shall contain the valid URI where the “TPEG Data Type” schema is to be found.
To achieve a common appearance of all tpegML schemas it is recommended to use “tdt” prefix for the
“TPEG Data Types” namespace.
When using an UML attribute of abstract data type, the tpegML schema shall contain the following
definition:

where UMLAttributeName is the name of the attribute as defined in UML, tdt is the prefix of the “TPEG
Data Types” namespace and AbstractDataType is one of the abstract data types defined in ISO 21219-2.
The syntax of abstract data types in tpegML format is described in Annex A.
XSD example:
xmlns: xs = ”http: //www .w3 .org/2001/XMLSchema”
targetNamespace=”http: //www .tisa .org/TPEG/[Specification Identification]”
xmlns: tdt = ”http: //www .tisa .org/TPEG/TPEGDataTypes _0 _0”
elementFormDefault=”qualified”
attributeFormDefault=”qualified”>
schemaLocation=”http: //www .tisa .org/TPEG/TPEGDataTypes _0 _0 .xsd”/>







4 © ISO 2019 – All rights reserved

XML example:


3
true

5.6 TPEG standard tables
The UML attributes of the TPEG standard table type shall be converted similar to abstract data types.
The “TPEG Data Types” schema contains definition for all TPEG standard tables.
The syntax of abstract data types is described in Annex A.
XSD example:
xmlns: xs = ”http: //www .w3 .org/2001/XMLSchema”
targetNamespace=”http: //www .tisa .org/TPEG/[Specification Identification]”
xmlns: tdt = ”http: //www .tisa .org/TPEG/TPEGDataTypes _0 _0”
elementFormDefault=”qualified”
attributeFormDefault=”qualified”>







XML example:

xmlns: tdt = ”http: //www .tisa .org/TPEG/TPEGDataTypes _0 _0“>



5.7 Application tables (stereotype <>)
The UML class with stereotype <> shall be converted to the XSD with the same syntax
as TPEG standard tables. The colon in the class name shall be replaced by an underscore “_”. The value
of the attribute “table” shall always contain this class name as fixed value.
To use a UML attribute of the application table type, the XSD shall contain the following complex type.
XSD example:










where applicationTableName is the name of the application table, xxxyyy is the application table prefix [1], and code is an
integer value up to 255
Accordingly the UML attribute of this type shall be:

5.8 Switching tables
Each child table of a switching table group shall be converted to the XSD according to the rule in 5.7. The
abstract parent class of a switching table group will be defined as standard application table with the
following conditions:
— The “table” attribute shall be defined as enumeration of all child table names;
— The “code” attribute shall not have any restrictions and shall always be set to “xs: unsignedByte” type.
The XSD example of the abstract blank class for a switching table group:






…






6 © ISO 2019 – All rights reserved

The XSD example for usage of a switching table type linked to a main table:

…


…

XML example for usage of a switching table depending on the set main table value:




…




There is no formal specification of the lookup value in the main table and the related switching table to
choose. The default relation is supposed to be 1 to 1. The special relation shall be defined in application
or toolkit specification.
If the restriction of the switching table “code” attribute is checked, the defined table for selected
switching table name shall be used.
5.9 Stereotype <>
The class with the stereotype <> defines a type which is defined in an external specification.
To use the <> type, the external specification shall provide either XML schema definition
or binary representation of this type. This rule defines usage of <> type for the following
external specifications:
— TISA TPEG application specification containing the <> type;
— Non-TISA specification containing XML schema definition for the <> type;
— Non-TISA specification containing only binary definition for the <> type.
5.9.1 TPEG application <> type
To use a class with the stereotype <> defined in a TISA TPEG application specification, the
prefix and the namespace of the <> TISA TPEG application shall be defined and imported.
The prefix will be used then to qualify the <> type. The prefix shall be set to the value defined
by the “tpegMLprefix” class tagged value. The namespace URI shall be set to the value defined by the
“tpegMLuri” class tagged value.
Additionally, the XML schema defined by the namespace shall be imported by adding the
element (see XSD example). The definition of the “schemaLocation” attribute within the
element can differ from the defined namespace URI but it shall contain the valid URI where the
<> TPEG application XML schema is to be found.
The local element from <> type shall be defined with type name set to class name from
which the class stereotyped as <> is derived. The name of class stereotyped as <>
is a placeholder only for the name of the class defined in a TPEG application specification.
Abstract classes may neither be imported nor used via this method. Instead each child class type shall
be imported.
XSD example:
xmlns: xs = ”http: //www .w3 .org/2001/XMLSchema”
targetNamespace=”http: //www .tisa .org/TPEG/[Specification Identification]“
xmlns: tdt = ”http: //www .tisa .org/TPEG/TPEGDataTypes _0 _0”

xmlns: ext1 = ”http: //www .tisa .org/TPEG/[External Application Identification]”
elementFormDefault=”qualified”
attributeFormDefault=”qualified”>

schemaLocation=”http: //www .tisa .org/TPEG/[External Application Identification].xsd” />









XML example:


xmlns: ext1 = ”http: //www .tisa .org/TPEG/[External Application Identification]”>
3
true

true
…


5.9.2 Non-TISA <> XML schema
To use a class with the stereotype <> defined in a non-TISA specification, but providing an
XML schema for the affected class, the same rule will be applied as for TPEG application <>
type except that the local element type name shall be set to the name of the class stereotyped as
8 © ISO 2019 – All rights reserved

<>. The class name, stereotyped as <>, is then the name of the class in the external
XML schema.
XSD example:
xmlns: xs = ”http: //www .w3 .org/2001/XMLSchema”
targetNamespace=”http: //www .tisa .org/TPEG/[Specification Identification]“
xmlns: tdt = ”http: //www .tisa .org/TPEG/TPEGDataTypes _0 _0”

xmlns: ext1 = ”http: //www .someuri .org”
elementFormDefault=”qualified”
attributeFormDefault=”qualified”>

schemaLocation=”http: //www .someuri .org/schema .xsd” />









XML example:


xmlns: ext1 = ”http: //www .someuri .org”>
3
true

true
…


5.9.3 Non-TISA <> binary type
To use a class with the stereotype <> defined in a non-TISA specification, which provides only
binary representation for the affected class, the local element type shall be set to “xs: base64Binary”.
XSD example:
xmlns: xs = ”http: //www .w3 .org/2001/XMLSchema”
targetNamespace=”http: //www .tisa .org/TPEG/[Specification Identification]“
xmlns: tdt = ”http: //www .tisa .org/TPEG/TPEGDataTypes _0 _0”
xmlns: ext1 = ”http: //www .tisa .org/TPEG/[External Application Identification]”
elementFormDefault=”qualified”
attributeFormDefault=”qualified”>









XML example:


xmlns: ext1 = ”http: //www .tisa .org/TPEG/[External Application Identification]”>
3
true
VGhhdCBpcyB0aGUgYmluYXJ5IHJlcHJlc2VudGF0aW9uIG9mIGEgbm9uLVRJU0EgZXh0ZXJu
YWwgc3BlY2lmaWNhdGlvbg==

5.10 Compound data types
5.10.1 Rule 1 — Classes
A class shall be converted into an XSD ComplexType with the name of the class.
The class stereotype <> shall be ignored.
The complex type of a class with tagged value ApplicationRoot shall be derived from
ApplicationRootMessageML defined in TPEG Service Framework specification ISO 21219-5.
UML XSD definition


10 © ISO 2019 – All rights reserved

UML XSD definition



XML Example:
QmluYXJ5IHRlc3RkYXRh




…




5.10.2 Rule 2 — Root element
A class with tagged value ApplicationRoot shall be present in an XSD as a global element with the
fixed name and the type of the corresponding XSD ComplexType. The name of the element shall be
“ApplicationRootMessageML”.
UML XSD definition

5.10.3 Rule 3 — Attributes
Rule 3 consists of four sub-rules, each specifying how to handle class attributes.
5.10.3.1 Rule 3a — Datatypes
Attributes of primitive data type shall be converted into xml format as defined in 5.5 and 5.7.
Attributes of compound data type shall be converted into xml format according to the rules in this
clause (5.10).
UML XSD definition





5.10.3.2 Rule 3b — Ordering
The order of the attributes as listed in the UML model shall be preserved.
UML XSD definition






5.10.3.3 Rule 3c — Single multiplicity [minOccurs = 1.maxOccurs = 1]
No additional rules apply.
5.10.3.4 Rule 3d — Multiplicity [minOccurs = 0.maxOccurs = 1], Multiplicity [minOccurs = 0.
maxOccurs > 1] and Multiplicity [minOccurs = 1. maxOccurs > 1]
The lower bound and upper bound of the attribute multiplicity shall be directly converted to
“minOccurs” and “maxOccurs” XML schema statements.
If the upper bound is set to “*” value the “maxOccurs” value shall be set then to “unbounded”.
UML XSD definition







maxOccurs=”unbounded”/>


12 © ISO 2019 – All rights reserved

UML XSD definition






5.10.3.5 Rule 3e — Attributes stereotyped with <> or
<>
The attributes stereotyped with <> shall be converted as a normal
attribute.
The attributes stereotyped as <> shall be combined under the xs: choice
element. Independent of the multiplicity of such attributes the defined element shall be always optional.
Multiple occurrence of such attributes will achieved by setting the occurrence of the xs: choice element
to unbounded.
UML XSD definition


minOccurs=”0” maxOccurs=”unbounded”/>

minOccurs=”0” />



5.10.4 Rule 4 — Specialisations/Abstract classes
5.10.4.1 Rule 4a — Inheritance
The UML inheritance is resolved in tpegML format by copying all attributes from parent class into the
child classes. The usage of XML inheritance feature is not allowed. The abstract parent class shall not
be available in the resulting XML schema unless it will be used for class switching (see Rule 5b). The
parent attributes shall occur before child attributes.
NOTE The use of inheritance is not allowed if a child class is stereotyped as <>.
UML XSD definition
















5.10.4.2 Rule 4b — Switching
The switching mechanism allows the generalization to be used as a selector mechanism to select only
one of the child components for instantiating. To convert this mechanism to tpegML notation, the UML
inheritance shall first be resolved according to rule 4a. The abstract parent class will then build the
switching class.
A complex type with name of the abstract parent class shall be created. This complex type shall contain
only the xs: choice of the multiplicity [1.1]. For each derived child component ,a choice element with
name and type of the derived child component and multiplicity of [1.1] shall be created. The name of
the choice element shall be prefixed with string “option”.
14 © ISO 2019 – All rights reserved

UML XSD definition
< xs: complexType name = ”SwitchingClass” >
< xs: choice >
< xs: element name = ”optionClassA” type = ”ClassA”/ >
< xs: element name = ”optionClassB” type = ”ClassB”/ >
< /xs: choice >
< /xs: complexType >
< xs: complexType name = ”ClassA” >
< xs: complexContent >
< xs: sequence >
< xs: element name = ”attr0” type = ”type0”/ >
< xs: element name = ”attr1” type = ”type1”/ >
< /xs: sequence >
< /xs: complexContent >
< /xs: complexType >
< xs: complexType name = ”ClassB” >
< xs: complexContent >
< xs: sequence >
< xs: element name = ”attr0” type = ”type0”/ >
< xs: element name = ”attr1” type = ”type2”/ >
< /xs: sequence >
< /xs: complexContent >
< /xs: complexType >
To use the switch construct an element shall be defined with type of switching class name.
XSD example:
< xs: complexType name = ”SomeClass”
…
< xs: element name = ”someattr” type = ”SwitchingClass” / >
…
< /xs: complexType >
XML example:
< someattr >
< optionClassA >
< attr0 > 123 < /attr0 >
< attr1 > 12345 < /attr1 >
< /optionClassA >
< /someattr >
or
< /someattr >
< optionClassB >
< attr0 > 123 < /attr0 >
< attr1 > abcdef < /attr1 >
< /optionClassB >
...