ISO 24531:2007

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

ISO 24531:2007 has been developed to assist developers and users of intelligent transport systems (ITS) standards who wish to use extensible markup language (XML), by providing a consistent definition of the rules and rule references for the use of XML within intelligent transport systems. The scope of ISO 24531:2007 is to define 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:2007 also provides guidance and examples in respect of the use of XML in ITS, and the elaboration of XML within the abstract syntax notation one (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: Withdrawn
• Publication Date: 18-Jun-2007
• Withdrawal Date: 18-Jun-2007
• 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: 9599 - Withdrawal of International Standard
• Start Date: 14-May-2013
• Completion Date: 13-Dec-2025

Relations

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

Standards Content (Sample)

INTERNATIONAL ISO
STANDARD 24531
First edition
2007-07-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 2007
PDF disclaimer
This PDF file may contain embedded typefaces. In accordance with Adobe's licensing policy, this file may be printed or viewed but
shall not be edited unless the typefaces which are embedded are licensed to and installed on the computer performing the editing. In
downloading this file, parties accept therein the responsibility of not infringing Adobe's licensing policy. The ISO Central Secretariat
accepts no liability in this area.
Adobe is a trademark of Adobe Systems Incorporated.
Details of the software products used to create this PDF file can be found in the General Info relative to the file; the PDF-creation
parameters were optimized for printing. Every care has been taken to ensure that the file is suitable for use by ISO member bodies. In
the unlikely event that a problem relating to it is found, please inform the Central Secretariat at the address given below.

©  ISO 2007
All rights reserved. Unless otherwise specified, no part of this publication may be reproduced or utilized in any form or by any means,
electronic or mechanical, including photocopying and microfilm, without permission in writing 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 2007 – All rights reserved

Contents Page
Foreword. iv
Introduction . v
1 Scope . 1
2 Conformance. 1
3 Normative references . 2
4 Terms and definitions. 2
5 Symbols and abbreviated terms . 8
6 Document convention . 9
7 Requirements . 9
7.1 Required conditions . 11
7.2 Required items . 11
7.3 Rules for using XML in ITS standards. 11
8 Rules for registration and management of XML Schema constructs in data registry (DR)
and/or data dictionaries (DDs). 19
8.1 Objectives of Schema constructs registration and management . 19
8.2 Why use ISO 14817 data registry/data dictionary (DR/DD)? . 19
8.3 ISO 14817 registration/management of Schema constructs. 21
8.4 Schema constructs mapping to the ISO 14818 constructs. 22
8.5 Registration and management rules. 23
Annex A (informative) Model/document transformation. 25
Annex B (informative) ISO/TC 204 representation of IRI(URI) and/or ID related constructs . 28
Annex C (informative) Schema header template. 29
Annex D (informative) Example of registering an XML construct. 34
Annex E (informative) Example of automatic generation of an XML schema from UML. 37
Annex F (informative) Applying ASN.1 encoding for XML document. 48
Annex G (informative) ASN.1 transformation to XML Schema example . 50
Bibliography . 60

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.
International Standards are drafted in accordance with the rules given in the ISO/IEC Directives, Part 2.
The main task of technical committees is to prepare International Standards. Draft International Standards
adopted by the technical committees are circulated to the member bodies for voting. Publication as an
International Standard requires approval by at least 75 % of the member bodies casting a vote.
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.
ISO 24531 was prepared by Technical Committee ISO/TC 204, Intelligent transport systems.

iv © ISO 2007 – All rights reserved

Introduction
As the exchange of information via the Internet and other wired and wire-free networks develops and expands,
the use of XML (extensible markup 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.
Within XML and its variants, however, 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 the definition of how to use XML and its variants in a consistent and
interoperable manner within the ITS sector.
INTERNATIONAL STANDARD ISO 24531:2007(E)

Intelligent transport systems — System architecture, taxonomy
and terminology — Using XML in ITS standards, data registries
and data dictionaries
1 Scope
The International Standard has been developed to assist developers and users of intelligent transport systems
(ITS) standards who wish to use extensible markup language (XML), by providing a consistent definition of the
rules and rule references for the use of XML within ITS systems. The scope of the International Standard is to
define 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 abstract syntax notation one (ASN.1) data definitions required by
ISO 14813-6 and ISO 14817.
This International Standard defines:
⎯ Rules concerning the creation of XML Schemas for ensuring interoperability in various types of ITS
applications that use XML (Clause 7, normative);
⎯ Rules for using XML for the purpose of reusing XML Schemas (Clause 7, normative);
⎯ Rules concerning registration and management of XML components in data dictionaries and data
registries (Clause 8, normative);
⎯ Examples of the use of XML in ITS applications (Annex A, informative);
⎯ Representation of IRI (international resource identifiers) and/or ID-related constructs of this standard
(Annex B, informative);
⎯ Schema header template (Annex C, informative);
⎯ Example of registering XML constructs (Annex D, informative);
⎯ Example of automatic generation of an XML Schema from unified modelling language (UML)
(Annex E, informative);
⎯ Applying ASN.1 encoding for XML document (Annex F, informative);
⎯ ASN.1 transformation to XML Schema example (Annex G, informative).
NOTE A table of language comparisons (XML, ASN.1, UML) may be found in ISO 14813-6.
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 schemas 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 internationally 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 31-0, Quantities and units ― Part 0: General principles
ISO/IEC 8824-1:2002, Information technology ― Abstract Syntax Notation One (ASN.1): Specification of basic
notation
ISO/IEC 8825-4:2002, Information technology ― ASN.1 encoding rules: XML Encoding Rules (XER)
ISO/IEC 8825-5:2004, Information technology ― ASN.1 encoding rules: Mapping W3C XML schema
definitions into ASN.1
ISO 14813-6, Transport information and control systems ― Reference model architecture(s) for TICS
sector ― Part 6: Data presentation in ASN.1
ISO 14817:2002, Transport information and control systems — Requirements for an ITS/TICS central Data
Registry and ITS/TICS Data Dictionaries
W3C Recommendation, Extensible Mark-up Language (XML) 1.0, Second Edition, 6 October 2000
W3C Recommendation, Namespaces in XML, 4 January 1999
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, 27 June 2001
OMG, XML Metadata Interchange (XMI) Specification, Version 2.0, 3 May 2003
OMG, Meta Object Facility (MOF) Specification, Version 2.0, April 2004
ISOC, RFC 3987: Internationalized Resource Identifiers (IRIs), January 2005
ISOC, RFC 2616: Hypertext Transfer Protocol — HTTP/1.1, June 1999
4 Terms and definitions
For the purposes of this document, the following terms and definitions shall apply.
4.1
application
program that reads XML documents and “does something useful” with them
NOTE Applications will normally be interfaced to an XML parser, for example via DOM or SAX.
2 © ISO 2007 – All rights reserved

4.2
ASN.1 application
application that uses ASN.1 encodings for communication (except XML encoding rules)
4.3
ASN.1 schema
definition of the content and structure of data using an ASN.1 type definition
NOTE ASN.1 is specified in ISO/IEC 8824.
4.4
association end
endpoint of an association, which connects the association to a classifier
4.5
attribute
〈classifier〉 feature that describes a range of values those instances of the classifier may hold
4.6
attribute
〈element〉 property
NOTE 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 are quoted with single or double quotes.
4.7
child element
element contained within another element
NOTE 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
4.10
constraint
semantic condition or restriction
NOTE 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 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]
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]
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]
NOTE 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 appear 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]
4.18
data type
type of content that an element contains in XML and UML
NOTE 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 © ISO 2007 – All rights reserved

4.22
EBNF
formal set of production rules that comprise a grammar defining language, such as XML
4.23
element
〈XML〉 logical data structure within an XML document, a piece of data within a file
NOTE 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.24
element
atomic constituent of the UML model
4.25
end tag
element delimiter
NOTE 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.26
Internet (uniform) resource identifier
IRI
compact string of characters for identifying an abstract or physical resource
4.27
lexical space
the set of valid literals for a datatype
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 The mark-up is not actually part of the content, but identifies the components and their roles.
4.30
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
[ISO14817]
4.31
metadata
data that defines and describes other data
4.32
namespace
set of unique identifiers
NOTE 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 uniform resource name (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.33
namespace
part of the model in which the names may be defined and used
NOTE Within a namespace, each name has a unique meaning.
4.34
namespace prefix
see prefix
4.35
node
elements, comments, processing instructions and text in an XML document
NOTE 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]
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 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 If the parser goes beyond the XML rules for conformance and validates the document against an XML
Schema (or DTD), 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 identify uniquely 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 A profile may also specify model libraries on which it depends and the metamodel subset that it extends.
6 © ISO 2007 – All rights reserved

4.42
property
named value, with semantic impact, denoting a characteristic of an element
NOTE Certain properties are predefined in the UML; others may be user defined (see tagged value).
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 Stereotypes are 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
tagged value
explicit definition of a property as a name-value pair; in a tagged value, the name is referred as the tag
NOTE Certain tags are predefined in the UML; others may be user defined. Tagged values are one of three
extensibility mechanisms in UML.
4.48
tags
text structures that mark up characters which mark the beginning and end of elements within the XML
document
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]
4.50
XMI
XML-based model interchange format for UML models
4.51
XML application
application that uses XML encoding
4.52
XML OID
XML representation of an ASN.1 OID
NOTE In the following example, the ASN.1 OID delimiter (white space) changed by a designated delimiter.
EXAMPLE
ASN.1 OID : iso standard 24531 schema 1
XML OID (delimiter "_"): iso_standard_24531_schema_1_v_1_._0
XML OID (delimiter "/"): iso/standard/24531/schema/1/v1.0
5 Symbols and abbreviated terms
ASN.1
abstract syntax notation one
BER
basic encoding rule
CER
canonical encoding rule
DD
data dictionary
DER
distinguished encoding rule
DR
data registry
DTD
document type definition
HTML
hypertext markup language
IRI
internationalized resource identifiers

ISO
International Organization for Standardization

ITS
intelligent transport system(s)

OID
object identifier
OMG
object management group
PER
packed encoding rule
RFC
request for comments
TICS
transport information and control system(s)

UML
unified modelling language
8 © ISO 2007 – All rights reserved

URL
uniform resource locator
W3C
World Wide Web consortium
WSDL
web services description language

XHTML
extensible hypertext markup language

XMI
XML metadata interchange
XML
extensible markup language
6 Document convention
In this International Standard the following documentation conventions are used:
a) The term “schema” with a small “s” is used generically (to include DTDs, XML Schema and in some case
ASN.1 schemas), while the term XML Schema or just Schema (capital “S”) refers specifically to schemas
authored in accordance with the World Wide Web Consortium (W3C) XML Schema recommendation.
b) For reasons of brevity, not all examples are full schemas. In all prose and examples, the xs name space
prefix is mapped to the namespace of the XML Schema language http://www.w3.org/2001/XMLSchema,
even if no namespace declaration appears in the example. Similarly, the xsi and xmi namespace prefixes
are mapped to the namespace name of Table 1.
Table 1 — Namespace prefix and associated namespace
Namespace prefix Associated Namespace
xs http://www.w3.org/2001/XMLSchema
xmi, xsi http://www.omg.org/2001/XMLSchema-instance

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 therefore informative. All IRIs in example are virtual
with the exception of http://www.w3.org/2001/XMLSchema.
e) Throughout this International Standard, in accordance with ISO 31-0, decimal separators will be a point
on the line.
7 Requirements
Figure 1 shows the scope of XML functionality in the ITS sector.
Figure 1 — XML functionality
10 © ISO 2007 – All rights reserved

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;
⎯ automatic generation of XML Schemas (or DTDs) from UML; and
⎯ rules for the automatic transformation between ASN.1 module to/from XML Schemas.
7.3 Rules for using XML in ITS standards
Rules for using XML and its variants in ITS standards are given below. Rules are described following usual
Schema development process. 7.3.1 defines the rules for designing Schema and Clause defines the rules for
Schema component definition.
A strictly conforming implementation shall be strictly conforming to the “REQUIREMENT” set.
7.3.1 Rules for XML Schema design
7.3.1.1 Use of the W3C XML Schema language
The W3C XML Schema language 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.3.1.2 Use of XML Schemas in preference to DTDs
XML Schema language shall be used to create schemas.
NOTE Within XML, DTDs are allowed to be used to create schemas. DTDs are simpler than XML Schema and can
provide a good fit for many text-oriented applications; however, ITS applications are generally not just text-oriented and
XML Schemas provide rich datatype definitions that improve the precision of vocabulary definition and document validation.
Also, the XML schema language supports “Namespace” that facilitates easier reuse of vocabulary. ITS applications shall
therefore use XML Schemas.
7.3.1.3 Use of subschema, linear dependency graphs
In order to promote reusability and code management, large schemas shall be constructed of smaller reusable
packages wherever possible, and there shall be a strictly linear dependency graph between subschemas.
NOTE XML allows cyclic and other complex references.
7.3.1.4 Explicit indication of version attribute and encoding attribute in XML declaration statement
When creating XML documents in ITS applications, the XML declaration statement shall be declared with the
XML version number attribute and encoding attribute explicitly indicated.
Because Schema syntax may be revised, the version number of a Schema shall be explicitly defined when the
Schema is created to ensure interoperability.
EXAMPLE

7.3.1.5 Declaration of version attribute in Schema elements
The version attribute shall be explicitly declared in Schema elements.
It is highly likely that applications that use XML will be revised, including extension of functions and deletion of
unnecessary functions. In such cases, the Schema is generally revised. It shall be clearly indicated which
version of a Schema is currently being used.
EXAMPLE
xmlns =”http://www.example.com/aa”
targetNamespace=”http://www.rxample.com/aa”
version = “1.0”>
...

NOTE Namespace and targetNamespace values are virtual.
7.3.1.6 Schema versioning rule
Released Schemas shall provide a version number in the form n.m (e.g. 1.2), and drafts also shall provide a
version number of the form n.ma (e.g. 1.2b).
7.3.1.7 Major version number rule
The major version number (n) shall be revised upwards when the change from the previous version of
Schema will cause existing documents to fail to validate.
7.3.1.8 Minor version number rule
The minor version number (m) shall be revised upwards when the change to the Schema will result in all
existing documents continuing to validate. However, some new documents, which validate against the new
version will fail against the old version.
12 © ISO 2007 – All rights reserved

7.3.1.9 Version letter rule
The version letter (a) shall be revised upwards every time a new draft is issued.
Indicating the version of a Schema is good practice and helps prevent problems caused by people
accidentally working with incorrect Schema versions. Therefore a common versioning rule and indicating the
Schema version attribute shall be used.
EXAMPLE
Listing 7-1 Version 1.0 document





xmlns:temp='http://www.iso. org' xmlns:xs='http://www.w3.org/2001/XMLSchema'>



New mandatory element “windVelocity” is added; therefore old version document fails to validate. Therefore,
new Schema shall be the incremented major version number.
7.3.1.10 Schema ID attributes in the Schema element
The Schema ID attribute of the Schema element shall normally be used to indicate the identity of the Schema.
The Schema ID attribute shall always use XML OID (delimiter “_”). (See Annex B.) The XML ID attribute is
given its value from the following rule: First three letters of ID are “iso”, after which follows number or identifier
of the ASN.1 OID. In the case of ASN.1 OID string include a white space, as a delimiter of the OID node, thus
“_” is used for XML ID. See ISO/IEC 8824-1 Annex D .
NOTE 1 Using XML OID as ID attribute of the Schema clarifies the application area and facilitates easy search of the
Schema and its constructs from the DR/DD.
NOTE 2 The lexical space of XML ID differs from that of the ASN.1 OID.
EXAMPLE

7.3.1.11 Explicit indication of targetNamespace in Schema elements
The targetNamespace shall be explicitly declared and shall be explicitly defined in Schema by
“http://"host"/"XML OID (delimiter "/”).
NOTE The namespace system facilitates use of the same names in many different fields without any naming
collisions. The use of XML in various ITS fields may lead to the same names being used even though they have different
meanings. The targetNamespace shall therefore be explicitly defined to facilitate the use of names without any collisions.
In respect of the term “host”, see IETF's rfc2616. The system manager decides the host.
EXAMPLE


7.3.1.12 Application of the targetNamespace+“xsd” for the schemaLocation
The targetNamespace “.xsd” naming convention shall be used as the schemaLocation.
NOTE The use of this convention will make it possible to infer the contents of a Schema from the file name.
EXAMPLE
http://www.its.org/iso/standard/24531/schema/1/v1.0a.xsd
7.3.1.13 Elements or attributes
Schemas shall be designed so that elements are the main holders of information content in the XML instances.
Attributes are more suited to holding ancillary metadata — simple items providing more information about the
element content. If the element containing the attribute has element content, any attributes shall normally
apply to all the descendant elements but are not mandatory.
NOTE Unlike elements, attributes cannot hold structured data. For this reason, elements are preferred as the
principal holders of information content. However, allowing the use of attributes to hold metadata about an element’s
content (for example, the format of a date, a unit of measure or the identification of a value set) can make an instance
document simpler and easier to understand. If an attribute were allowed to qualify other attributes, there could arise cases
with multiple attributes where it would not be clear whether an attribute was qualifying the element or one of several
attributes. Therefore, attributes are not allowed to qualify other attributes.
7.3.1.14 Data type or element declarations
A component may be defined as a data type if either:
⎯ it is to be used with different element names in different contexts; or
⎯ it is expected that further data types will be derived from it.
A component shall be defined as an element if:
⎯ there is no intention to derive new components from it; and
⎯ the element is to be used with its name unchanged.
NOTE There are many circumstances in which an element should be used with its name unchanged. For example, if
a “Unique LOCATION” always has the name “Unique LOCATION”, its semantics will be known and two systems using the
same element will be known to be using the same definition. It is therefore possible to build a dictionary of element names
with known interoperable semantics. However, there are other circumstances where it is not appropriate to allocate a
name to an element at the time a Schema is developed. For example, an address could have several meanings and so be
used with different names. An address should therefore be defined as a global data type. The other circumstance for
choosing between an element and a data type to define a component is if there is an intention to derive other components
from it. By only using data types in this instance, we simplify understanding of Schemas by only having a single
14 © ISO 2007 – All rights reserved

inheritance mechanism and avoiding use of xs:redefine for this purpose. In some cases in a Schema, it is appropriate to
define both a data type and an element. The element is then available with known fixed semantics for reuse and the data
type available for appropriate modification.
7.3.1.15 Use of complex types
In order to enable future reuse of compound elements, or to allow for the use of inheritance in its own
definition, complex structures shall be used for elements that represent all significant (that is semantically
discrete) objects, including request and response themselves.
7.3.1.16 Global definitions
Schema documents should make available globally those component definitions that are either:
⎯ re-used within the Schema; or
⎯ to be made available for re-use in other Schemas (import, include).
NOTE The main reason for this approach is to limit the effect of change. By keeping component definitions local, it is
easy to control who else uses these definitions and so limit the impact of change.
7.3.1.17 Use of documentation element and language attribute
When documenting a Schema, the documentation element shall be used rather than XML comments.
NOTE The “documentation” element contains a human readable annotation to a Schema. Using “documentation”
element, “source” attribute supplementing outer documentation information and “xml:lang” attribute support multi-natural
language description.
7.3.1.18 Containing schema header in every schema
The Schema header shall be defined with reference to Table 2.
Table 2 — Schema header item
Header Item Description
General information
Schema name Described by ID attribute
Functional area Classified functional area name by ISO 14813 or common area
Description Plain text description of the type of information described by the Schema
Version number Version number of the released or draft Schema
Current status (Released/ Draft)
Standard title Related standard title of the Schema, if extant
Standard number Related standard number of the Schema, if extant
Detail explanation IRI Detail explanation IRI of the Schema, if extant
Namespace targetNamespace of the schema (See 7.3.1.11)
Schema location URL of the Schema (See 7.3.1.12)
Validated by Schema validation software name
UML location UML (CLASS Diagram) of the Schema, if extant
DR/DD information DR/DD Information of the Schema, if extant
Code table IRI Code table IRI of the Schema, if extant
Enumeration IRI Enumeration IRI, if extant
Change history
Version number Release or draft version number
Date Version number change date
Description of change Plain text description
Other Schemas imported
Schema name Imported Schema names, if extant
Description Plain text description of the type of information imported by the Schema
Namespace Namespace of the imported Schema
Schema location Schema location of the imported Schema
Other Schemas included
Schema name Included Schema names
Description Plain text description of the type of information included by the Schema
Schema location Schema location of the included schema
Point of contact
Name Name of person to contact with questions regarding the Schema
e-mail address E-mail address to contact with questions regarding the Schema

NOTE 1 By adhering a header to the schema, the schema becomes an interoperability tool and promotes reuse of the
schema, because analysts can read it and understand the meaning and derivation of various XML components. It also
expected to increase the maintainability of the system.
NOTE 2 Using Annex C Schema header template, 7.3.1.17 conformant header can be authored.
16 © ISO 2007 – All rights reserved

EXAMPLE




********** ********** ********** ********** **********

iso standard 14532 schema header
ITS common
This schema is a template for creating ISO
24531conformant schema header
1.0a
Draft
Using XML in ITS standard, data registries and data
dictionaries
ISO 24531
http://www.example.com/iso/standard/24531/schema/1/v1.0a.xsd tailExplanationIRI>
http://www.example.com/iso/standard/24531/schema/1
ABC Schema editor v6.0
http://www.example.com/iso/standard/schema/1/v1.0a.cls
all data concept, including this schema are registered to
the ISO 14817 data registry
None
None


None


None


iso_standard_schema_2
general information template
http://www.iso.standard/iso/standard/23531/schema/2/v1.0a.xsd ocation>  iso_standard_schema_3
change history template
http://www.iso.standard/iso/standard/23531/schema/3/v1.0a.xsd ocation>
iso_standard_schema_4
other schema imported template
http://www.iso.standard/iso/standard/23531/schema/4/v1.0a.xsd ocation>
iso_standard_schema_5
other schema included template
http://www.iso.standard/iso/standard/23531/schema/5/v1.0a.xsd ocation>
iso_standard_schema_6
contact information template
http://www.iso.standard/iso/standard/23531/schema/6/v1.0a.xsd ocation>



A B
[e-mail]
X Y
x.y@tc20

********** ********** ********** ********** **********


…

7.3.1.19 External table reference
Where an external table is provided, reference IRI shall be included.
NOTE Because a code table is often extended, reference to a maintained external table means that there is no need
for revision with each change to the code table.
EXAMPLE

xlink:type="simple"
xlink:title="wind direction code table"
xlink:href="http://www.example.com>
...