ISO/IEC 19516:2020

INTERNATIONAL ISO/IEC
STANDARD 19516
First edition
2020-02
Information technology — Object
management group — Interface
definition language (IDL) 4.2
Reference number
ISO/IEC 19516:2020(E)
©
ISO/IEC 2020

---------------------- Page: 1 ----------------------
ISO/IEC 19516:2020(E)

COPYRIGHT PROTECTED DOCUMENT
© ISO/IEC 2020
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: +41 22 749 01 11
Fax: +41 22 749 09 47
Email: copyright@iso.org
Website: www.iso.org
Published in Switzerland
ii © ISO/IEC 2020 – All rights reserved

---------------------- Page: 2 ----------------------
ISO/IEC 19516:2020(E)
Contents
Foreword . v
Introduction . v
1 Scope . 1
1.1 Overview . 1
2 Conformance Criteria . 1
3 Normative References . 2
4 Terms and Definitions . 2
5 Symbols . 2
6 Additional Information . 3
6.1 Acknowledgments . 3
6.2 History . 3
7 IDL Syntax and Semantics . 4
7.1 Overview . 4
7.2 Lexical Conventions . 5
7.2.1 Tokens . 8
7.2.2 Comments . 8
7.2.3 Identifiers . 8
7.2.4 Keywords . 9
7.2.5 Other Characters Recognized by IDL . 10
7.2.6 Literals . 11
7.3 Preprocessing . 13
7.4 IDL Grammar . 13
7.4.1 Building Block Core Data Types . 14
7.4.2 Building Block Any . 30
7.4.3 Building Block Interfaces — Basic . 31
7.4.4 Building Block Interfaces — Full . 37
7.4.5 Building Block Value Types . 39
7.4.6 Building Block CORBA-Specific — Interfaces . 42
7.4.7 Building Block CORBA-Specific — Value Types . 48
7.4.8 Building Block Components — Basic . 53
7.4.9 Building Block Components — Homes . 56
7.4.10 Building Block CCM-Specific . 59
7.4.11 Building Block Components — Ports and Connectors . 64
7.4.12 Building Block Template Modules . 67
7.4.13 Building Block Extended Data-Types . 70
7.4.14 Building Block Anonymous Types . 76
7.4.15 Building Block Annotations . 77
7.4.16 Relationships between the Building Blocks . 80
7.5 Names and Scoping . 81
7.5.1 Qualified Names . 81
7.5.2 Scoping Rules and Name Resolution . 82
7.5.3 Special Scoping Rules for Type Names . 84
8 Standardized Annotations . 86
8.1 Overview . 86
8.2 Introduction . 86
8.2.1 Rules for Defining Standardized Annotations . 86
8.2.2 Rules for Using Standardized Annotations . 86
8.3 Standardized Groups of Annotations . 86
8.3.1 Group of Annotations General Purpose . 86
8.3.2 Group of Annotations Data Modeling . 89
© ISO/IEC 2020 – All rights reserved iii

---------------------- Page: 3 ----------------------
ISO/IEC 19516:2020(E)
8.3.3 Group of Annotations: Units and Ranges . 89
8.3.4 Group of Annotations Data Implementation . 91
8.3.5 Group of Annotations Code Generation . 91
8.3.6 Group of Annotations Interfaces . 92
9 Profiles . 93
9.1 Overview . 93
9.2 CORBA and CCM Profiles . 93
9.2.1 Plain CORBA Profile . 93
9.2.2 Minimum CORBA Profile . 94
9.2.3 CCM Profile . 94
9.2.4 CCM with Generic Interaction Support Profile . 94
9.3 DDS Profiles . 95
9.3.1 Plain DDS Profile . 95
9.3.2 Extensible DDS Profile . 95
9.3.3 RPC over DDS Profile . 95
Annex A Consolidated IDL Grammar . 97
iv © ISO/IEC 2020 – All rights reserved

---------------------- Page: 4 ----------------------
ISO/IEC 19516:2020(E)
Foreword
ISO (the International Organization for Standardization) and IEC (the International Electrotechnical Commission) form
the specialized system for worldwide standardization. National bodies that are members of ISO or IEC participate in the
development of International Standards through technical committees established by the respective organization to deal
with particular fields of technical activity. ISO and IEC technical committees collaborate in fields of mutual interest.
Other international organizations, governmental and non-governmental, in liaison with ISO and IEC, also take part in the
work.
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 document should
be noted (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
and IEC 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) or the IEC list of patent declarations received (see http://patents.iec.ch).
(see
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 the Object Management Group (OMG) (as the OMG specification for Interface
Definition Language (IDL), v4.2) and drafted in accordance with its editorial rules. It was adopted, under the JTC 1 PAS
procedure, by Joint Technical Committee ISO/IEC JTC 1, Information technology.
This document is related to:
• ITU-T Recommendation X.902 (1995) | ISO/IEC 10746-2:1995, Information Technology — Open Distributed
Processing — Reference Model: Foundations
• ITU-T Recommendation X.903 (1995) | ISO/IEC 10746-3:1995, Information Technology — Open Distributed
Processing — Reference Model: Architecture
• ITU-T Recommendation X.920 (1997) | ISO/IEC 14750:1997, Information Technology — Open Distributed
Processing — Interface Definition Language
Apart from this Foreword, the text of this document is identical with that for the OMG specification for Interface
Definition Language (IDL), v4.2.
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.
© ISO/IEC 2020 – All rights reserved v

---------------------- Page: 5 ----------------------
ISO/IEC 19516:2020(E)
Introduction
The rapid growth of distributed processing has led to a need for a coordinating framework for this standardization and
ITU-T Recommendations X.901-904 | ISO/IEC 10746, the Reference Model of Open Distributed Processing (RM-ODP)
provides such a framework. It defines an architecture within which support of distribution, interoperability, and
portability can be integrated.
RM-ODP Part 2 (ISO RM-ODP Part 2 (ISO/IEC 10746-2) defines the foundational concepts and modeling framework
for describing distributed systems. The scopes and objectives of the RM-ODP Part 2 and the UML, while related, are not
the same and, in a number of cases, the RM-ODP Part 2 and the UML specification use the same term for concepts which
are related but not identical (e.g., interface). Nevertheless, a specification using the Part 2 modeling concepts can be
expressed using UML with appropriate extensions (using stereotypes, tags, and constraints).
RM-ODP Part 3 (ISO/IEC 10746-3) specifies a generic architecture of open distributed systems, expressed using the
foundational concepts and framework defined in Part 2. Given the relation between UML as a modeling language and
Part 3 of the RM-ODP standard, it is easy to show that UML is suitable as a notation for the individual viewpoint
specifications defined by the RM-ODP.
This International Standard defines a method for automating the counting of Function Points that is generally consistent
with the Function Point Counting Practices Manual, Release 4.3.1 (IFPUG CPM) produced by the International Function
Point Users Group (IFPUG). Guidelines in this International Standard may differ from those in the IFPUG CPM at points
where subjective judgments have to be replaced by the rules needed for automation. The IFPUG CPM was selected as the
anchor for this International Standard because it is the most widely used functional measurement specification with a
large supporting infrastructure maintained by a professional organization.
vi © ISO/IEC 2020 – All rights reserved

---------------------- Page: 6 ----------------------
INTERNATIONAL STANDARD ISO/IEC 19516:2020(E)

Information technology — Object management group —
Interface definition language (IDL) 4.2
1 Scope
1.1 Overview
This International Standard specifies the OMG Interface Definition Language (IDL). IDL is a descriptive language
used to define data types and interfaces in a way that is independent of the programming language or operating
system/processor platform.
The IDL specifies only the syntax used to define the data types and interfaces. It is normally used in connection with
other standards that further define how these types/interfaces are utilized in specific contexts and platforms:
•  Separate “language mapping” standards define how the IDL-defined constructs map to specific programming
languages, such as, C/C++, Java, C#, etc.
•  Separate “serialization” standards define how data objects and method invocations are serialized into a format
suitable for network transmission.
•  Separate “middleware” standards, such as, DDS or CORBA leverage the IDL to define data-types, services, and
interfaces.
The description of IDL grammar uses a syntax notation that is similar to Extended Backus-Naur Format (EBNF).
2 Conformance Criteria
This International Standard defines IDL such that it can be referenced by other standards. It contains no independent
conformance points. It is up to the standards that depend on this International Standard to define their own conformance
criteria. However, the general organization of the clauses (by means of atomic building blocks and profiles that group
them) is intended to ease conformance description and scoping. That means that no standard using IDL 4.0 will be forced
to be compliant with IDL constructs that are not relevant in its usage of IDL.
Conformance to this International Standard must follow these rules:
1. Future standards that use IDL shall reference this IDL International Standard or a future revision thereof.
2. Future revisions of current standards that use IDL may reference this IDL International Standard or a future revision
thereof.
3. Reference to this International Standard shall result in a selection of building blocks possibly complemented by
groups of annotations.
a. All selected building blocks shall be supported entirely.
b. Selected annotations shall be either supported as described in 8.2.2 Rules for Using Standardized Annotations,
or fully ignored. In the latter case, the IDL-dependent standard shall not define a specific annotation, either with
the same name and another meaning or with the same meaning and another name.
© ISO/IEC 2020 – All rights reserved 1

---------------------- Page: 7 ----------------------
ISO/IEC 19516:2020(E)
3 Normative References
The following referenced documents are indispensable for the application of this International Standard. For dated
references, only the edition cited applies. For undated references, the latest edition of the referenced document
(including any amendments):
•  ISO/IEC 14882:2003, Information Technology — Programming languages — C++
•  [RFC2119] IETF RFC 2119, "Key words for use in RFCs to Indicate Requirement Levels", S. Bradner, March 1997.
Available from http://ietf.org/rfc/rfc2119
•  [CORBA] Common Object Request Broker Architecture. OMG specification: formal/2012-11-12 (part1),
formal/2012-11-14 (part2), formal/2012-11-16 (part3)
The following referenced documents were used as input to this International Standard:
•  [DDS-XTypes]. Extensible and Dynamic Topic Types for DDS, Version 1.2. Available from:
http://www.omg.org/spec/DDS-XTypes/1.2
•  [DDS]. Data Distribution Service, Version 1.4. Available from: http://www.omg.org/spec/DDS/1.4
• [DDS-RPC]. Remote Procedure Call over DDS, Version 1.0. Available from:
   http://www.omg.org/spec/DDS-RPC/1.0
4 Terms and Definitions
In this International Standard:
•  A building block is a consistent set of IDL rules that together form a piece of IDL functionality. Building blocks are
atomic, meaning that if selected, they must be totally supported. Building blocks are described in Clause 7, IDL
Syntax and Semantics.
•  A group of annotations is a consistent set of annotations, expressed in IDL. Groups of annotations are described in
Clause 8, Standardized Annotations.
•  A profile is a selection of building blocks possibly complemented with groups of annotations that determines a
specific IDL usage. Profiles are described in Clause 9, Profiles.
5 Symbols
The following abbreviations are used throughout this International Standard.
Acronym Meaning
ASCII American Standard Code for Information Interchange
BIPM Bureau International des Poids et Mesures
CCM CORBA Component Model
CORBA Common Object Request Broker Architecture
DDS Data Distribution Service
EBNF Extended Backus Naur Form
2 © ISO/IEC 2020 – All rights reserved

---------------------- Page: 8 ----------------------
ISO/IEC 19516:2020(E)
Acronym Meaning
IDL Interface Definition Language
ISO International Organization for Standardization
LwCCM Lightweight CCM
OMG Object Management Group
ORB Object Request Broker
XTypes eXtensible and dynamic topic Types (for DDS)
6 Additional Information
6.1 Acknowledgments
The following companies submitted this International Standard:
—  Thales
—  RTI
The following companies supported this International Standard:
—  Mitre
—  Northrop Grumman
—  Remedy IT
6.2 History
Historically, IDL was designed to specify CORBA interfaces and subsequently CORBA components. For this reason
the IDL standard was embedded in the CORBA documentation. However its expressive power made it very suitable
for defining non-CORBA interfaces and data types. Consequently, it was used in the DDS standard and extended to
support that usage. In recognition of these new usages, and expected future ones, IDL was separated into its own
stand-alone standard, independent of its use by specific middleware technologies.
This International Standard completes the definition of IDL as a separate standard, an effort started with IDL 3.5.
IDL 3.5 gathered in a single standard all the CORBA-dedicated IDL, formerly specified as a collection of clauses
within the CORBA 3 standard.
IDL 4.0 extended that corpus with the other source for IDL definitions, namely "Extensible and Dynamic Topic Types
for DDS" in order to group all IDL constructs in a single comprehensive standard. It organized the IDL description
into modular "Building Blocks" so that different levels of compliance are easier to specify and that future evolutions,
if needed, can be made without side-effects on existing IDL usages.
IDL 4.1 improved the definition of the bitset type, added a bitmap type, and resolved some inconsistencies in the
grammar.
IDL 4.2 added support for 8-bit integer types, added size-explicit keywords for integer types, enhanced the readability,
and reordered the building blocks to follow a logical dependency progression.
© ISO/IEC 2020 – All rights reserved 3

---------------------- Page: 9 ----------------------
ISO/IEC 19516:2020(E)
7 IDL Syntax and Semantics
7.1 Overview
1 2
This clause describes OMG Interface Definition Language (IDL) middleware -agnostic semantics and defines the
syntax for IDL grammatical constructs.
3
OMG IDL is a language that allows unambiguous specification of the interfaces that client objects may use and (server)
object implementations provide as well as all needed related constructs such as exceptions and data types. Data types are
needed to specify parameters and return value of interfaces' operations. They can be used also as first class constructs.
IDL is a purely descriptive language. This means that actual programs that use these interfaces or create the associated
data types cannot be written in IDL, but in a programming language, for which mappings from IDL constructs have been
defined. The mapping of IDL constructs to a programming language will depend on the facilities available in that
programming language. For example, an IDL exception might be mapped to a structure in a language that has no notion
of exceptions, or to an exception in a language that does. The binding of IDL constructs to several programming
languages is described in separate standards.
The clause is organized as follows:
•  The description of IDL’s lexical conventions is presented in 7.2 Lexical Conventions.
•  A description of IDL preprocessing is presented in 7.3 Preprocessing
•  The grammar itself is presented in 7.4 IDL Grammar
•  The scoping rules for identifiers in an IDL standard are described in 7.5.
IDL-specific pragmas may appear anywhere in a standard; the textual location of these pragmas may be semantically
constrained by a particular implementation.
A source file containing specifications written in IDL shall have a ".idl" extension.
The description of IDL grammar uses a syntax notation that is similar to Extended Backus-Naur Format (EBNF).
However, to allow composition of specific parts of the description, while avoiding redundancy; a new operator (::+)
has been added. This operator allows adding alternatives to an existing definition. For example, assuming the rule x
::= y, the rule x ::+ z shall be interpreted as x ::= y | z.
Table 7.1 lists the symbols used in this EBNF format and their meaning.

1
In this document the word middleware refers to any piece of software that will make use of IDL-derived artifacts. CORBA and
  DDS implementations are examples of middleware. The word compiler refers to any piece of software that produces these
  IDL-derived artifacts based on an IDL specification.

2
I.e., abstract semantics that is applicable to all IDL usages. When needed, middleware-specific interpretations of that abstract
  semantics will be given afterwards in dedicated clauses.

3
 Accordingly, client objects should be understood here as abstract clients, i.e., entities invoking operations provided by object
  implementations, regardless of the means used to perform this invocation or even whether those implementations are
  co-located or remotely accessible.
4 © ISO/IEC 2020 – All rights reserved

---------------------- Page: 10 ----------------------
ISO/IEC 19516:2020(E)
Table 7.1 — IDL EBNF
Symbol Meaning
::=
Is defined to be (left part of the rule is defined to be right part of the rule)
|
Alternatively
::+
Is added as alternative (left part of the rule is completed with right part of the
rule as a new alternative)

Nonterminal
"text"
Literal
*
The preceding syntactic unit can be repeated zero or more times
+
The preceding syntactic unit must be repeated at least once
{}
The enclosed syntactic units are grouped as a single syntactic unit
[] The enclosed syntactic unit is optional – may occur zero or one time

7.2 Lexical Conventions
4
This sub clause presents the lexical conventions of IDL. It defines tokens in an IDL specification and describes
comments, identifiers, keywords, and literals - integer, character, and floating point constants and string literals.
An IDL specification logically consists of one or more files. A file is conceptually translated in several phases.
The first phase is preprocessing, which performs file inclusion and macro substitution. Preprocessing is controlled by
directives introduced by lines having # as the first character other than white space. The result of preprocessing is a
sequence of tokens. Such a sequence of tokens, that is, a file after preprocessing, is called a translation unit.
IDL uses the ASCII character set, except for string literals and character literals, which use the ISO Latin-1 (8859-1)
character set. The ISO Latin-1 character set is divided into alphabetic characters (letters) digits, graphic characters, the
space (blank) character, and formatting characters. Table 7.2 shows the ISO Latin-1 alphabetic characters; upper and
lower case equivalences are paired. The ASCII alphabetic characters are shown in the left-hand column of Table 7.2.
Table 7.2 — Characters
Char. Descript
...