ISO 24531:2013

Intelligent transport systems - System architecture, taxonomy and terminology - Using XML in ITS standards, data registries and data dictionaries

ISO 24531:2013 assists ITS standards developers and users of ITS standards who wish to use XML, by providing a consistent definition of the rules and rule references for the use of XML within ITS systems. ISO 24531:2013 defines consistent rules and rule references to provide a framework to be used when implementing XML-based applications in ITS, and particularly in specifying XML in ITS standards, ITS data registries and ITS data dictionaries. ISO 24531:2013 also provides guidance and examples in respect of the use of XML in ITS, and the elaboration of XML within the ASN.1 data definitions required by ISO 14813-6 and ISO 14817.

Systèmes intelligents de transport — Architecture, taxinomie et terminologie des systèmes — Usage de XML dans les normes, registres de données et dictionnaires de données, en ITS

General Information

• Status: Published
• Publication Date: 13-May-2013
• ICS: 35.240.60 - IT applications in transport
• Technical Committee: ISO/TC 204 - Intelligent transport systems
• Drafting Committee: ISO/TC 204/WG 1 - Architecture
• Current Stage: 9093 - International Standard confirmed
• Start Date: 15-Aug-2022
• Completion Date: 13-Dec-2025

Relations

• Revises: ISO 24531:2007 - Intelligent transport systems - System architecture, taxonomy and terminology - Using XML in ITS standards, data registries and data dictionaries
• Effective Date: 25-Sep-2010

Overview

ISO 24531:2013 - "Intelligent transport systems - System architecture, taxonomy and terminology - Using XML in ITS standards, data registries and data dictionaries" - defines a consistent framework for using XML and its variants across Intelligent Transport Systems (ITS). The standard helps ITS standards developers and users specify XML-based data exchanges, register and manage XML schema constructs in ITS data registries and data dictionaries, and align XML with ASN.1 representations required by related ITS standards.

Key topics and requirements

• Consistent XML rules: Clause 7 prescribes required conditions, items and rules for modelling data exchanges and for using XML in ITS standards to maximise interoperability and reuse.
• Schema registration and management: Clause 8 describes objectives and rules for registering XML schema constructs in ITS data registries/data dictionaries, and how schema constructs map to ISO 14817/ISO 14818 constructs.
• Guidance and examples: The standard includes normative and informative annexes with XML schema patterns, message components, example request/response schemas, transformation files (XSLT), and code-list handling (Genericode).
• Interoperability focus: ISO 24531 is a conceptual model - it does not mandate a single physical implementation but requires consistent design choices to claim conformance.
• Integration with ASN.1 and UML: Provides guidance on elaborating XML from ASN.1 data definitions and aligns with UML modelling practices where relevant.
• Normative references: Refers to W3C XML/XSD/XLink/XSLT recommendations, OASIS Genericode, and ISO ITS registry standards (e.g., ISO 14817).

Applications

• Standardising XML message formats and schemas for ITS services such as traffic management, traveler information, and data exchange between transport centres.
• Creating and maintaining ITS data registries and data dictionaries to ensure consistent metadata, value domains and message definitions.
• Defining transformation workflows (e.g., XSLT) and schema mappings between XML and ASN.1 for systems that use hybrid encodings.
• Supporting regional or national ITS implementations by providing a reusable framework that allows local schema extensions while preserving international interoperability.

Who should use this standard

• ITS standards developers and working groups creating XML message specifications.
• System architects and data modelers implementing ITS data registries/data dictionaries.
• Software engineers and integrators building ITS applications, XML schemas, XSLT transformations, or ASN.1-to-XML mappings.
• Policy-makers and procurement teams requiring interoperable ITS data exchange specifications.

Related standards

• ISO 14817 (ITS data registry and data dictionary)
• ISO 14818/14813-6 (ASN.1/UML comparisons)
• W3C XML/XSD/XSLT recommendations
• OASIS Genericode (code-list representation)

Using ISO 24531:2013 helps ensure interoperable, maintainable and reusable XML-based data exchanges across intelligent transport systems worldwide.

Standards Content (Sample)

INTERNATIONAL ISO
STANDARD 24531
Second edition
2013-06-01
Intelligent transport systems —
System architecture, taxonomy and
terminology — Using XML in ITS
standards, data registries and data
dictionaries
Systèmes intelligents de transport — Architecture, taxinomie et
terminologie des systèmes — Usage de XML dans les normes, registres
de données et dictionnaires de données, en ITS
Reference number
©
ISO 2013
© ISO 2013
All rights reserved. Unless otherwise specified, 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
Case postale 56 • CH-1211 Geneva 20
Tel. + 41 22 749 01 11
Fax + 41 22 749 09 47
E-mail [e-mail]
Web www.iso.org
Published in Switzerland
ii © ISO 2013 – All rights reserved

Contents Page
Foreword .v
Introduction .vi
1 Scope . 1
2 Conformance . 1
3 Normative references . 1
4 Terms and definitions . 2
5 Abbreviated terms . 7
6 Document convention . 8
7 Requirements . 9
7.1 Required conditions . 9
7.2 Required items . 9
7.3 Rules for modelling data exchanges . 9
7.4 Rules for using XML in ITS standards .12
8 Rules for registration and management of XML schema constructs in data registry (DR)
and/or data dictionaries (DDs) .34
8.1 Objectives of schema constructs registration and management .34
8.2 Why use ISO 14817 data registry/ data dictionary (DR/DD)? .35
8.3 Schema constructs mapping to the ISO 14818 constructs .35
8.4 Registration and management rules .36
Annex A (informative) Model/document transformation.37
Annex B (normative) Definition of the Message class .40
Annex C (informative) Example Message Exchange: Model .47
Annex D (normative) Unqualified data types schema .50
Annex E (normative) Common basic components schema .68
Annex F (normative) Common aggregate components schema .72
Annex G (normative) Common extension components schema .79
Annex H (normative) Extension content data type schema .82
Annex I (normative) Common message components schema .84
Annex J (informative) Example message exchange: request message schema.86
Annex K (informative) Example message exchange: response message schema .88
Annex L (informative) Example message exchange: default genericode files .90
Annex M (informative) Example message exchange: default context value association file .95
Annex N (informative) Example CVA transformation file .97
Annex O (informative) Example message exchange: default value validation transformation file .99
Annex P (informative) Example message exchange: customized genericode files .101
Annex Q (informative) Example message exchange: customized context value association file .104
Annex R (informative) Example message exchange: customized value validation
transformation file .106
Annex S (informative) Example message exchange: customized extension content data
type schema .108
Annex T (informative) Example message exchange: customized data type definition .112
Annex U (informative) Example message exchange: example request .113
Annex V (informative) Example message exchange: example responses .114
Annex W (informative) Comparison Between ISO 24531 and UBL NDR 2.1 .117
Bibliography .123
iv © ISO 2013 – All rights reserved

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. 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. 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.
The committee responsible for this document is ISO/TC 204, Intelligent Transport Systems.
This second edition cancels and replaces the first edition (ISO 24531:2006). Clause 7 onwards has been
technically revised.
Introduction
As the exchange of information via the internet and other wired and wire-free networks develops and
expands, the use of XML (Extended Mark-up Language) and its variants continues to grow and develop.
XML will be an important tool in the development and operation of “Intelligent Transport Systems”
(ITS) services.
However, within XML and its variants there are options. In order to obtain maximum benefit,
interoperability and re-use of data within the ITS sector, it is important to implement XML and its
variants in a consistent manner.
This International Standard provides definitions of how to use XML and its variants in a consistent and
interoperable manner within the ITS sector.
vi © ISO 2013 – All rights reserved

INTERNATIONAL STANDARD ISO 24531:2013(E)
Intelligent transport systems — System architecture,
taxonomy and terminology — Using XML in ITS standards,
data registries and data dictionaries
1 Scope
This International Standard assists ITS standards developers and users of ITS standards who wish to
use XML, by providing a consistent definition of the rules and rule references for the use of XML within
ITS systems. This International Standard defines consistent rules and rule references to provide a
framework to be used when implementing XML-based applications in ITS, and particularly in specifying
XML in ITS standards, ITS data registries and ITS data dictionaries. This International Standard also
provides guidance and examples in respect of the use of XML in ITS, and the elaboration of XML within
the ASN.1 data definitions required by ISO 14813-6 and ISO 14817.
NOTE A table of language comparisons (XML, ASN.1, UML) can be found in ISO 14813-6:2009.
2 Conformance
This International Standard prescribes a conceptual model; it does not define any single physical
implementation. It provides a consistent and interoperable means of achieving interoperability for the
international exchange of information in XML application programs. Regional and national XML schema
have the option of providing additional schema and variants for use in local situations.
In order to claim conformance with this International Standard, it is only required to design systems
and exchange data consistently in accordance with the provisions of this International Standard. No
external conformance procedures are proposed or defined in this International Standard, although
regional, national and local implementations are free to, and may choose to, define and require local
conformance procedures.
3 Normative references
The following referenced documents are indispensable for the application 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 14812:1999, Transport information and control systems — Glossary standard terminologies for the
transport information and control sector
ISO 14817:2002, Transport information and control systems — Requirements for an ITS/TICS central Data
Registry and ITS/TICS Data Dictionaries
ISO/IEC 19501:2005, Information technology — Open Distributed Processing — Unified Modeling Language
(UML) Version 1.4.2
W3C Recommendation, Extensible Mark-up Language (XML) 1.0 (Fifth Edition), 26 November 2008
W3C Recommendation, Namespaces in XML 1.0 (Second Edition), 16 August 2006
W3C Recommendation, XML Schema Part 1: Structures (Second Edition), 28 October 2004
W3C Recommendation, XML Schema Part 2: Datatypes (Second Edition), 28 October, 2004
W3C Recommendation, XML Linking Language (XLink), Version 1.0, 27 June 2001
W3C Recommendation, XSL Transformations (XSLT), Version 2.0, 23 January 2007
OASIS, Code List Representation (Genericode), Version 1.0, December 2007
OASIS, Context/value association using genericode 1.0, April 2010
ISOC, RFC 5141, A Uniform Resource Name (URN) Namespeace for the International Organization for
Standardization (ISO), March 2008
4 Terms and definitions
For the purposes of this document, the terms and definitions given in ISO 14812 and the following apply.
4.1
application
program that reads XML documents and “does something useful” with them
Note 1 to entry: Applications will normally be interfaced to an XML parser, for example via DOM or SAX.
4.2
ASN.1 application
application that uses ASN.1 encodings for communication (except XER)
4.3
ASN.1 schema
definition of the content and structure of data using an ASN.1 type definition
4.4
association end
endpoint of an association, which connects the association to a classifier
4.5
attribute
property of an element
Note 1 to entry: It is additional information about a piece of data (element). Often attributes are used to pass
information about the element and hence can be said to provide metadata for the element. An attribute is a value
indicator (=) and the attribute value is specified within the tag (i.e.

). Attribute in XML is a
name=”value” pair that can be placed in the start tag of an element. For XML, all values have to be quoted with
single or double quotes.
4.6
attribute
feature within a classifier that describes a range of values those instances of the classifier may hold
4.7
child element
element contained within another element
Note 1 to entry: The element containing other elements is a parent element.
4.8
class
description of a set of objects that share the same attributes, operations, methods, relationships,
and semantics
4.9
class diagram
diagram that shows a collection of declarative (static) model elements, such as classes, types,
and their contents and relationships
2 © ISO 2013 – All rights reserved

4.10
constraint
semantic condition or restriction
Note 1 to entry: Certain constraints are predefined in the UML, others may be user defined. Constraints are one
of three extensibility mechanisms in UML.
4.11
content
all data between the start tag and end tag of an element
Note 1 to entry: Content may be made up of mark-up characters and character data.
4.12
content model
expression specifying what elements and data are allowed within an element
4.13
data concept
any of a group of data dictionary structures defined in ISO 14817 (i.e. object class, property, value domain,
data element concept, data element, data frame, message, interface dialogue, association) referring to
abstractions or things in the natural world that can be identified with explicit boundaries and meaning
and whose properties and behaviour all follow the same rules
[ISO 14817:2002, definition 4.4]
4.14
Data Dictionary
organized and constructed (electronic data base) compilation of descriptions of data concepts
that provides a consistent means for documenting, storing and retrieving the syntactical form (i.e.
representational form) and the meaning and connotation of each data concept
[ISO 14817:2002, definition 4.6]
4.15
data element
data concept; some single unit of information of interest (such as a fact, proposition, observation, etc.) about
some (entity) class of interest (e.g. a person, place, process, property, concept, association, state, event)
[ISO 14817:2002, definition 4.7]
Note 1 to entry: A data element is considered to be indivisible in a particular context.
4.16
data frame
data concept; grouping of data elements primarily for the purpose of referring to the group with a single
name, and thereby efficiently reusing groups of data elements that commonly appears together (as an
ASN.1 SEQUENCE, SEQUENCE OF, SET, SET OF or CHOICE) in a message specification
4.17
data registry
store of data, characterized in a consistent manner, as determined according to the provisions of this
International Standard, used for a specific purpose (in this case ITS)
[ISO 14817:2002, definition 4.11]
4.18
data type
type of content that an element contains in XML and UML
Note 1 to entry: An author can specify an element’s data type.
4.19
declaration
create new types (both simple and complex)
4.20
definition
enable elements and attributes with specific names and types (both simple and complex) to
appear in document instances
4.21
document type definition
rules that define the tags that can be used in an XML file and their valid values
4.22
element
logical data structure within an XML document, a piece of data within a file
Note 1 to entry: An XML element consists of a start tag, and end tag, and the information between the tags, which
is often referred to as the contents. Start tags and end tags show the beginning and end of an element. A schema
that can provide a description of the structure of the data describes elements used in an XML file.
4.23
element
atomic constituent of the UML model
4.24
end tag
element delimiter
Note 1 to entry: In: this is a bar the construct is the end-tag. End tags cannot include anything
other than the element name and trailing space.
4.25
global
construct (e.g. element, group, attribute, attribute group, or data type) that is declared as a direct child
of the schema root element
4.26
internet (uniform) resource identifier
IRI
compact string of characters for identifying an abstract or physical resource
4.27
lexical space
set of valid literals for a data type
4.28
local
element, group, attribute, attribute group, or data types that are not global
4.29
mark-up
identification of element types and structure within a document
Note 1 to entry: The mark-up is not actually part of the content, but identifies the components and their roles.
4.31
message
data concept; grouping of data elements and/or data frames as well as associated message metadata,
that is used to convey a complete unit of information
[ISO 14817:2002, definition 4.19]
4 © ISO 2013 – All rights reserved

4.32
metadata
data that defines and describes other data
4.33
namespace
set of unique identifiers
Note 1 to entry: Namespace is a mechanism to resolve naming conflicts between elements in an XML document
when each comes from a different vocabulary. It allows the commingling of like tag names from different
namespaces. A namespace identifies an XML vocabulary defined within a URN. An attribute on an element,
attribute, or entity reference associates a short name with the URN that defines the namespace; that short name
is then used as a prefix to the element, attribute, or entity reference name to uniquely identify the namespace.
Namespace references have scope. All child nodes beneath the node that specifies the namespace inherit that
namespace. This allows nonqualified names to use the default namespace.
4.34
namespace
part of the model in which the names may be defined and used
Note 1 to entry: Within a namespace, each name has a unique meaning.
4.35
node
elements, comments, processing instructions, and text in an XML document
Note 1 to entry: An XML document has a hierarchical structure, described as a tree. The tree has branches
connecting at the nodes.
4.36
object class
data concept; construct used to represent any kind of object (also referred to as an entity) within an
ITS/TICS information environment
[ISO 14817:2002, definition 4.25]
4.37
OID
globally unique value associated with an object to identify it unambiguously
4.38
package
general purpose mechanism for organizing elements into groups
Note 1 to entry: Packages may be nested within other packages.
4.39
parser (for XML)
processor that reads an XML document and determines the structure and properties of the data
Note 1 to entry: If the parser goes beyond the XML rules for conformance and validates the document against
an XML schema, the parser is said to be a “validating” parser. A generalized XML parser reads XML files and
generates a hierarchically structured tree, then hands off data to viewers and other applications for processing.
A validating XML parser also checks the XML syntax and reports errors.
4.40
prefix
namespace prefix
short name to uniquely identify the namespace
4.41
profile
stereotyped package that contains model elements, which have been customized for a specific
domain or purpose using extension mechanisms, such as stereotypes, tagged definitions and constraints
Note 1 to entry: A profile may also specify model libraries on which it depends and the metamodel subset that it extends.
4.42
property
named value denoting a characteristic of an element
Note 1 to entry: Certain properties are predefined in the UML; others MAY be user defined. See: tagged value.
Note 2 to entry: A property has semantic impact.
4.43
role
named specific behaviour of an entity participating in a particular context
4.44
schema
system of representing an information model that defines the data’s elements and attributes
4.45
schema processor
processor to validate schema
4.46
stereotype
new type of modelling element that extends the semantics of the metamodel
Note 1 to entry: Stereotypes have to be based on certain existing types or classes in the metamodel. Stereotypes
may extend the semantics, but not the structure of pre-existing types and classes. Certain stereotypes are
predefined in the UML, others may be user defined. Stereotypes are one of three extensibility mechanisms in UML.
4.47
tags
text structures that mark-up characters which mark the beginning and end of elements within
the XML document
4.48
tagged value
explicit definition of a property as a name-value pair
Note 1 to entry: Certain tags are predefined in the UML; others MAY be user defined. Tagged values are one of
three extensibility mechanisms in UML.
Note 2 to entry: In a tagged value, the name is referred as the tag.
4.49
value domain
data concept; expression of a specific and explicit representation of some information about something
of interest within the ITS/TICS domain
[ISO 14817:2002, definition 4.29]
4.50
XMI
XML-based model interchange format for UML models
6 © ISO 2013 – All rights reserved

4.51
XML application
application that uses XML encoding
4.52
XML OID
XML representation of an ASN.1 OID
EXAMPLE In the following example, the ASN.1 OID delimiter (white space) changed by a designated delimiter.
ASN.1 OID : iso standard 24531 schema 1; XML OID (delimiter “_”): iso_standard_24531_schema_1; XML OID
(delimiter “/”): iso/standard/24531/schema/1
5 Abbreviated terms
ASN.1
abstract syntax notation one
DD
data dictionary
DR
data registry
HTML
hyper text markup language
IRI
Internationalized Resource Identifiers
ISO
International Organization for Standardization
ITS
intelligent transport system(s)
NDR
naming and design rules
OID
object identifier
OMG
object management group
RFC
request for comments
TICS
transport information and control system(s)
UBL
unifversal business language
URL
uniform resource locator
UML
unified modelling language (as defined by ISO 19501)
W3C
world wide web consortium
WSDL
web services description language
XHTML
extensible hyper text mark-up language
XMI
XML metadata interchange
XML
eXtensible mark-up language
6 Document convention
In this International Standard the following documentation conventions are used.
a) The term ‘schema’ refers specifically to schemas authored in accordance with the World Wide Web
Consortium (W3C) XML schema recommendation, unless otherwise indicated.
b) For reasons of brevity, not all examples are full schemas. In all prose and examples, the mappings
shown in Table 1 apply, even if no namespace declaration appears in the example.
Table 1 — Namespace prefix and associated namespace
Namespace prefix Associated Namespace
xs http://www.w3.org/2001/XMLSchema
xsi http://www.w3.org/2001/XMLSchema-instance
xmi http://www.omg.org/2001/XMI
EXAMPLE

In this case, it is understood that

has already been declared.
c) Even if no end tag appears in the example, assume the end tag is declared at the appropriate place.
d) All examples are only for the purpose of explanation and are therefore informative. All IRIs in the
examples are virtual with the exception of the namespaces listed in Table 1.
e) Throughout this International Standard, in accordance with ISO 31-0:1992, Amd. 2:2005, decimal
separators will be a point on the line.
8 © ISO 2013 – All rights reserved

7 Requirements
Figure 1 shows the scope of XML functionality in the ITS sector.
Figure 1 — XML functionality
7.1 Required conditions
Intelligent transport systems are evolving social infrastructure systems that offer various functions. To
achieve their benefits, the following exchanges occur:
— information exchanges between various countries’ organizations, including web services usages;
— information exchanges between different ITS functional areas;
— information exchanges between ITS-related industries’ systems; and
— information exchanges through various networks.
7.2 Required items
From the viewpoint of ITS information technology, the following items are required:
— formal method to define precise and unambiguous ITS vocabularies;
— registration and management rules for XML components, management and maintenance rules (ITS
data registries and ITS data dictionaries);
— formal method to define dialogues and messages;
— expandable and reusable vocabularies and programs;
— ways to support various networks (wired/mobile/DSRC/digital broadcast /CALM, etc.);
— efficient encoding method; and
— automatic generation of XML schemas from UML.
7.3 Rules for modelling data exchanges
NOTE Annex C contains a complete example of a modeled data exchange.
7.3.1 Model each data exchange
Every data exchange shall be modeled using a UML sequence diagram. See Figure 2 for an example.
Figure 2 — Sample sequence diagram
NOTE The production of sequence diagrams also facilitates the generation of computer code in various
languages and with reverse engineering tools, code/diagram synchronization becomes possible.
7.3.1.1 Identify the entities exchanging messages
The UML sequence diagram shall identify the sender and recipient of each message.
7.3.1.2 Identify the messages exchanged
The UML sequence diagram shall identify the name of each message exchanged in the sequence without
the colon or “message” term.
EXAMPLE For a message with the Descriptive Name “IncidentList():message”, the name of the UML message
in the sequence diagram would be “IncidentList()”.
7.3.2 Model each message
Every message shall be modeled using a UML class diagram. Figure 3 shows an example.
Figure 3 — Sample UML class diagram depicting a message
10 © ISO 2013 – All rights reserved

7.3.2.1 Use the <> stereotype
A message shall be modeled as a UML class with the stereotype <>.
7.3.2.2 Specialize from the Message class
A message shall be defined to be a specialization of the generic Message class. The Message class shall
be as defined in Annex B.
7.3.2.3 Message name
The name of the UML class representing the message shall be the Descriptive Name of the message
without the parenthesis, colon, or “message” term.
EXAMPLE For a message with the Descriptive Name “IncidentList():message”, the UML class name would be
“IncidentList”.
7.3.2.4 Message contents
All message contents shall be modeled as either properties or associated data frames.
7.3.3 Modeling properties
If a property of an object class is relevant to a message, it shall be modeled as a UML attribute of its
parent data frame or message.
NOTE In other words, a message (or data frame) is really just a view of an object class. The object class
may have additional properties and associations not included in the message (or data frame) definition, but the
message (or data frame) may not include any properties or associations not defined for the parent object class.
Figure 4 provides an example.
Object class view        Message view
Figure 4 — Object class view vs. message view
7.3.4 Modeling associations
If an association of an object class is relevant to a message, it shall be modeled as a UML directional
composition to a UML class with the stereotype <>.
NOTE In other words, for the purposes of messaging, the message is comprised of the smaller data frames
and if a message is lost, so are all of the data frames that it contains. However, the receiving system may loosen the
association between the message and data frames such that when the parent entity is deleted from the system,
the detailed data may be retained, if desired.
7.3.4.1 Contents of UML classes
A data frame or message shall only contain properties and associations from a single object class.
NOTE In other words, in the above example, Person.name:text is placed in its own data frame even though
that data frame has only one attribute defined. This is because a parallel structure to the base data model is
being created. Alternatively, the designer could modify the base data model to create a new property (Vehicle.
driverName:text) and then place this new property as an attribute of the VehicleDetails message.
7.3.4.2 Role of associated data frame
The association role assigned to the associated UML class shall be the role of the ITS data
dictionary/registry association.
NOTE This is often the name of the dataframe, but may be different. For example, the “Person” dataframe
may be assigned a role of “user”, “driver”, “employee”, etc.
7.4 Rules for using XML in ITS standards
Rules for using XML and its variants in ITS standards are described in the subclauses that follow.
7.4.1 Rules for XML file organization
In order to promote reusability and code management, schemas shall be constructed of smaller reusable
packages wherever possible. The packages shall follow the modular structure as defined by the following
subclauses and depicted in Figure 5. Details about each file shown in this schema are provided in 7.4.2
through 7.4.16.
NOTE 1 The file organization and the format of each file is based on UBL Naming and Design Rules (NDR) 2.1
with slight variances to accommodate the ITS domain and management structures. A comparison between UBL
NDR and this International Standard is provided in Annex W.
NOTE 2 Electronic versions of the files cited in the following clauses may be accessed at http://standards.iso.
org/iso/24531/
12 © ISO 2013 – All rights reserved

Figure 5 — Relationship among XML interface definition files
7.4.1.1 Unqualified data types schema
The unqualified data types schema provides the definition of each fundamental data type that can be
used in ISO/TC 204 standards. All ISO/TC 204 message sets use the same unqualified data types schema,
as defined in Annex D.
7.4.1.2 Common basic components schema
The common basic components schema provides the definition of all properties used by a particular set
of messages. All ISO/TC 204 message sets shall be based on the same common aggregate components
schema, as defined in Annex E. However, it is recognized that there may be a large number of properties
within the full scope of ISO/TC 204. In order to accommodate manageable, modular deployments,
individual working groups may modify the common aggregate components schema, but only to “include”
additional aggregate components schema files.
7.4.1.3 Common aggregate components schema
The common aggregate components schema provides the definition of all data frames, associations, and
data elements used by a particular set of messages. All ISO/TC 204 message sets shall use the same common
aggregate components schema, as defined in Annex F. However, it is recognized that there may be a large
number of data frames, associations, and data elements within the full scope of ISO/TC 204. In order to
accommodate manageable, modular deployments, individual working groups may modify the common
aggregate components schema, but only to “include” additional aggregate components schema files.
7.4.1.4 Common extension components schema
The common extension components schema provides the definition of how to create an extension to
a standardized message. It defines the structure that contains the extension along with a variety of
metadata, including the version of the extension, the agency who defined the extension, etc. All ISO/TC 204
message sets shall use the same default extension content data type schema, as defined in Annex G.
7.4.1.5 Extension content data type schema
The extension content data type schema is a standardized schema that serves as a placeholder to allow
for extensions to the standard. All ISO/TC 204 message sets shall use the same default extension content
data type schema, as defined in Annex H.
7.4.1.6 Customized extension content data type schema
The customized extension content data type schema is a schema produced by an implementer who
wishes to extend the standard message set by referencing other schemas. An example of such a schema
is provided in Annex S.
7.4.1.7 Customized data type definitions
The customized data type definitions schemas are the set of schemas that the implementer wishes to
use to extend the standardized message set. An example of such a schema is provided in Annex T.
7.4.1.8 Common message component schema
The common message components schema provides the definition of the message structure that should
be used by all ISO/TC 204 messages. It defines a structure that supports extensions and identifies each
message with a version id. All ISO/TC 204 message sets shall use the same common message components
schema, as defined in Annex I.
7.4.1.9 Message schemas
A message schema provides the definition of a single message by referencing elements previously
defined in the common message components schema, the common aggregate components schema, and
the common basic components schema. This file is unique to each message type. Examples for such a
schema are provided in Annex J and Annex K.
14 © ISO 2013 – All rights reserved

7.4.1.10 Code list definition (genericode files)
Each code list shall be defined in its own genericode file, as per the rules defined by OASIS. Code lists
shall be defined by the messaging standard with a clear indication whether support for each defined
value is mandatory or optional. In the latter case, the code list may be customized by an implementation
to define the actual code list supported. Example genericode files are provided in Annex L.
7.4.1.11 Context-value associations
The valid codes for a given context shall be defined in a context-value association file, per the rules
defined by OASIS. The context-value association file, and any portion thereof, shall be defined by the
messaging standard with a clear indication whether each rule is mandatory or advisory. In the latter
case, the context-value associations may be customized by an implementation to define the actual values
supported. An example context-value association file is provided in Annex M.
7.4.1.12 Value validation transformation files
A value validation transformation file is an EXtensible Stylesheet Language Transformation (XSLT)
file produced by performing a standard XSLT transformation on the context-value association file (and
referenced genericode files). The result is an XSLT file that can verify that the values contained in an
XML document (i.e., an actual instance of a ITS message) are valid. Annex N provides a sample XSLT
transformation file that can be used to transform a CVA file into the XSLT format. Annex O provides an
example value validation transformation file produced by applying the Annex N stylesheet to the CVA
file defined in Annex M.
7.4.1.13 Circular dependencies
There shall be a strictly linear dependency graph between sub schemas. Circular dependencies are not
allowed among schema files.
7.4.2 General rules for XML schema
7.4.2.1 Use of the W3C XML schema language
The W3C XML schema language, as defined by the W3C Recommendations listed as normative references
to this International Standard, shall be used as the descriptive language for schemas when using XML
for International Standards.
NOTE Although there are other descriptive languages for schemas, such as RELAX NG, use of the W3C XML
schema language is overwhelmingly predominant in applications written in XML. The W3C XML schema language
is used to enable interoperability with other applications.
7.4.2.2 Availability of schemas
All referenced schema files shall be accessible while an application using a specific message schema is in use.
NOTE When an instance document is input, the schema syntax is designed such that validation is performed
regardless of whether the processor references the schema or not. Ordinarily, however, a processor references
the schema in performing the validation process, and it is thought that such a method shall normally be
provided. The basis for doing that is the schema files. Accordingly, the schema file shall be accessible so long as
the application is in use.
7.4.2.3 Naming uniqueness
Within any namespace, a name shall be used only once and shall not be repeated even if it is a different
type of data.
NOTE Additional naming rules are defined in this International Standard that further specify how to produce
data type names that are different from element names and that ensure that attributes are only defined in the
unqualified data type schema.
7.4.2.4 Rules for schema types
7.4.2.4.1 Any
The xsd:any type shall not be used, except in the construct of the ExtensionComponentDataType.
7.4.2.4.2 Any Type
The xsd:anyType type shall not be used.
7.4.2.5 Rules for use of elements within schema definitions
7.4.2.5.1 All
The xsd:all element shall not be used.
7.4.2.5.2 App Info
The xsd:appInfo element should be avoided and used only to express non-normative information.
7.4.2.5.3 Choice
The xsd:choice element should not be used where customization and/or extensibility may be needed.
NOTE The list of options in a required choice statement cannot be extended without breaking backwards
compatibility. For example, there may be a variety of ways to describe a location, and the number of ways may
increase over time. Rather than using a choice element, it would be better to define one required location format
and then allow a series of optional location formats to provide for alternative methods. That approach maximizes
interoperability among systems. However, a choice element may be appropriate where the list of options is not
expected to ever grow.
7.4.2.5.4 Import
The xsd:import element shall only be used to import a schema from a different namespace.
7.4.2.5.5 Include
The xsd:include element shall only be used to include a schema in the same namespace.
7.4.2.5.6 Notation
The xsd:notation element shall not be used.
7.4.2.5.7 Redefine
The xsd:redefine element shall not be used.
NOTE This is to avoid pervasive side-effects in reused components, and to increase clarity and readability.
16 © ISO 2013 – All rights reserved

7.4.2.5.8 Union
The xsd:union element shall not be used.
7.4.2.6 Rules for use of attributes within schema definitions
7.4.2.6.1 Final
The “final” attribute shall not be used, except in extensions where there is a desire to prohibit future
extensions.
7.4.2.6.2 Mixed
The “mixed” attribute shall not be used. Mixed content is not allowed.
7.4.2.6.3 Nillable
The “nillable” attribute shall not be used.
7.4.2.6.4 Substitution Group
The “substitutionGroup” attribute shall not be used.
7.4.2.7 Attributes
Attributes shall only be defined within the unqualified data types schema to define the base data types
used to represent all data.
7.4.2.8 No empty elements
Empty elements shall not be declared.
7.4.2.9 Range checking
ISO/TC 204 standards shall not define normative ranges for values within a schema.
NOTE The mechanisms within XML that define valid data ranges do not provide the necessary flexibility to
allow for proper customization, localization, extension, and version control. Instead, this International Standard
recommends defining valid values through a separate approach using context-value association files.
7.4.2.10 Documentation
Each schema shall be provided in two forms: an annotated version to assist in human consumption
and a version without any annotation for run-time use. The annotated version shall contain annotation
elements and XML comments as discussed within this International Standard and as otherwise deemed
valuable to the human understanding of the schema contents; the non-annotated version shall not
contain any annotation elements or comments.
EXAMPLE



...