SIST EN ISO 29481-2:2026

SLOVENSKI STANDARD
01-marec-2026
Nadomešča:
SIST EN ISO 29481-2:2016
Informacijski modeli stavb - Priročnik z informacijami - 2. del: Okvirni podatki o
medsebojnem vplivanju (ISO 29481-2:2025)
Building information models - Information delivery manual - Part 2: Interaction framework
(ISO 29481-2:2025)
Bauwerksinformationsmodelle - Handbuch der Informationslieferungen - Teil 2:
Interaktionsframework (ISO 29481-2:2025)
Modèles des informations de la construction - Protocole d’échange d’informations -
Partie 2: Cadre d'interaction (ISO 29481-2:2025)
Ta slovenski standard je istoveten z: EN ISO 29481-2:2025
ICS:
35.240.67 Uporabniške rešitve IT v IT applications in building
gradbeništvu and construction industry
91.010.01 Gradbeništvo na splošno Construction industry in
general
2003-01.Slovenski inštitut za standardizacijo. Razmnoževanje celote ali delov tega standarda ni dovoljeno.

EN ISO 29481-2
EUROPEAN STANDARD
NORME EUROPÉENNE
December 2025
EUROPÄISCHE NORM
ICS 35.240.67 Supersedes EN ISO 29481-2:2016
English Version
Building information models - Information delivery
manual - Part 2: Interaction framework (ISO 29481-
2:2025)
Modèles des informations de la construction - Bauwerksinformationsmodelle - Handbuch der
Protocole d'échange d'informations - Partie 2: Cadre Informationslieferungen - Teil 2:
d'interaction (ISO 29481-2:2025) Interaktionsframework (ISO 29481-2:2025)
This European Standard was approved by CEN on 20 December 2025.

CEN members are bound to comply with the CEN/CENELEC Internal Regulations which stipulate the conditions for giving this
European Standard the status of a national standard without any alteration. Up-to-date lists and bibliographical references
concerning such national standards may be obtained on application to the CEN-CENELEC Management Centre or to any CEN
member.
This European Standard exists in three official versions (English, French, German). A version in any other language made by
translation under the responsibility of a CEN member into its own language and notified to the CEN-CENELEC Management
Centre has the same status as the official versions.

CEN members are the national standards bodies of Austria, Belgium, Bulgaria, Croatia, Cyprus, Czech Republic, Denmark, Estonia,
Finland, France, Germany, Greece, Hungary, Iceland, Ireland, Italy, Latvia, Lithuania, Luxembourg, Malta, Netherlands, Norway,
Poland, Portugal, Republic of North Macedonia, Romania, Serbia, Slovakia, Slovenia, Spain, Sweden, Switzerland, Türkiye and
United Kingdom.
EUROPEAN COMMITTEE FOR STANDARDIZATION
COMITÉ EUROPÉEN DE NORMALISATION

EUROPÄISCHES KOMITEE FÜR NORMUNG

CEN-CENELEC Management Centre: Rue de la Science 23, B-1040 Brussels
© 2025 CEN All rights of exploitation in any form and by any means reserved Ref. No. EN ISO 29481-2:2025 E
worldwide for CEN national Members.

Contents Page
European foreword . 3

European foreword
This document (EN ISO 29481-2:2025) has been prepared by Technical Committee ISO/TC 59
"Buildings and civil engineering works" in collaboration with Technical Committee CEN/TC 442
“Building Information Modelling (BIM)” the secretariat of which is held by SN.
This European Standard shall be given the status of a national standard, either by publication of an
identical text or by endorsement, at the latest by June 2026, and conflicting national standards shall be
withdrawn at the latest by June 2026.
Attention is drawn to the possibility that some of the elements of this document may be the subject of
patent rights. CEN shall not be held responsible for identifying any or all such patent rights.
This document supersedes EN ISO 29481-2:2016.
Any feedback and questions on this document should be directed to the users’ national standards
body/national committee. A complete listing of these bodies can be found on the CEN website.
According to the CEN-CENELEC Internal Regulations, the national standards organizations of the
following countries are bound to implement this European Standard: Austria, Belgium, Bulgaria,
Croatia, Cyprus, Czech Republic, Denmark, Estonia, Finland, France, Germany, Greece, Hungary, Iceland,
Ireland, Italy, Latvia, Lithuania, Luxembourg, Malta, Netherlands, Norway, Poland, Portugal, Republic of
North Macedonia, Romania, Serbia, Slovakia, Slovenia, Spain, Sweden, Switzerland, Türkiye and the
United Kingdom.
Endorsement notice
The text of ISO 29481-2:2025 has been approved by CEN as EN ISO 29481-2:2025 without any
modification.
International
Standard
ISO 29481-2
Second edition
Building information models —
2025-12
Information delivery manual —
Part 2:
Interaction framework
Modèles des informations de la construction — Protocole
d’échange d’informations —
Partie 2: Cadre d’interaction
Reference number
ISO 29481-2:2025(en) © ISO 2025

ISO 29481-2:2025(en)
© ISO 2025
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
Email: copyright@iso.org
Website: www.iso.org
Published in Switzerland
ii
ISO 29481-2:2025(en)
Contents Page
Foreword .iv
Introduction .v
1 Scope . 1
2 Normative references . 1
3 Terms and definitions . 1
3.1 General .2
3.2 Technical components.2
4 Notation . 2
5 Interaction framework . 3
5.1 General .3
5.2 Information management and the interaction framework .3
5.3 Purpose of an interaction framework .5
5.4 Hierarchical structure of an interaction framework .5
5.4.1 General .5
5.4.2 Roles .6
5.4.3 Transactions .7
5.4.4 Messages .8
5.4.5 Complex and simple elements .10
5.5 Establishing a digital IDM communication project .10
5.5.1 General .10
5.5.2 Modelling the interaction framework .11
5.5.3 Creating and using the interaction framework schema .11
5.5.4 Using a project specific message to link a person to roles . 12
5.5.5 Executing digital IDM communication . 12
5.5.6 Validating digital IDM communication . 13
5.5.7 Signing messages with advanced electronic signatures . 13
5.5.8 Changing the project during execution .14
5.5.9 Archiving digital IDM communication.14
6 Schemas for validating interaction frameworks and messages .15
6.1 Basic principles . 15
6.2 Types of elements .16
6.3 Element types in the interaction framework schema and _2 EXPRESS source file .17
6.3.1 General .17
6.3.2 Primary element types .18
6.3.3 Secondary element types . 28
6.3.4 References .31
6.4 Element types in the interaction message schema and the _5 EXPRESS source file .37
6.4.1 General .37
6.4.2 Primary element types . 38
6.4.3 Secondary element types .43
6.4.4 References .45
Annex A (normative) Interaction framework schema definition .51
Annex B (normative) Templates definition .52
Annex C (informative) Promotor algorithm .53
Annex D (informative) Example interaction framework XML of a simplified design office use
case .54
Annex E (informative) Example project specific message XML of a simplified design office use
case . 67
Annex F (informative) Example message XML of a simplified design office use case .72

iii
ISO 29481-2:2025(en)
Foreword
ISO (the International Organization for Standardization) is a worldwide federation of national standards
bodies (ISO member bodies). The work of preparing International Standards is normally carried out through
ISO technical committees. Each member body interested in a subject for which a technical committee
has been established has the right to be represented on that committee. International organizations,
governmental and non-governmental, in liaison with ISO, also take part in the work. ISO collaborates closely
with the International Electrotechnical Commission (IEC) on all matters of electrotechnical standardization.
The procedures used to develop this document and those intended for its further maintenance are described
in the ISO/IEC Directives, Part 1. In particular, the different approval criteria needed for the different types
of ISO documents should be noted. This document was drafted in accordance with the editorial rules of the
ISO/IEC Directives, Part 2 (see www.iso.org/directives).
ISO draws attention to the possibility that the implementation of this document may involve the use of (a)
patent(s). ISO takes no position concerning the evidence, validity or applicability of any claimed patent
rights in respect thereof. As of the date of publication of this document, ISO had not received notice of (a)
patent(s) which may be required to implement this document. However, implementers are cautioned that
this may not represent the latest information, which may be obtained from the patent database available at
www.iso.org/patents. ISO shall not be held responsible for identifying any or all such patent rights.
Any trade name used in this document is information given for the convenience of users and does not
constitute an endorsement.
For an explanation of the voluntary nature of standards, the meaning of ISO specific terms and expressions
related to conformity assessment, as well as information about ISO's adherence to the World Trade
Organization (WTO) principles in the Technical Barriers to Trade (TBT), see www.iso.org/iso/foreword.html.
This document was prepared by Technical Committee ISO/TC 59, Buildings and civil engineering works,
Subcommittee SC 13, Organization and digitization of information about buildings and civil engineering
works, including building information modelling (BIM), in collaboration with the European Committee
for Standardization (CEN) Technical Committee CEN/TC 442, Building Information Modelling (BIM), in
accordance with the Agreement on technical cooperation between ISO and CEN (Vienna Agreement).
This second edition cancels and replaces the first edition (ISO 29481-2:2012), which has been technically
revised.
The main changes are as follows:
— introduced updates that better integrate the interaction framework within the concept of digital IDM
communication;
— aligned terminology and practices with other related standards.
A list of all parts in the ISO 29481 series can be found on the ISO website.
Any feedback or questions on this document should be directed to the user’s national standards body. A
complete listing of these bodies can be found at www.iso.org/members.html.

iv
ISO 29481-2:2025(en)
Introduction
Collaboration between the participants involved during the life cycle of assets is pivotal to the efficient
delivery and operation of assets. Organizations collaborate within specific use cases to achieve higher levels
of quality and greater re-use of existing knowledge, information experience and resources. A significant
condition of collaboration is the opportunity to communicate, re-use and share information efficiently, and
to reduce the risk of loss, contradiction or misinterpretation.
The ISO 29481 series on the information delivery manual (IDM) provides significant assistance in making
the most of information management. If the necessary information is available at the right time, the quality
of the information is satisfactory and the right person is involved at the right time, the collaboration and
outcome itself is greatly improved. Since management and coordination rely heavily on communication,
it benefits from being well structured, unambiguous, explicit and timely. This is supported by a common
understanding of the purpose, the processes, the actors involved and the information needed.
This document focuses on the foundations for and execution of digital communication in accordance with
the processes and information requirements of a use case. With a focus on communication, this document
offers a natural complement to standards that focus on information management such as the ISO 19650
series, information containers such as the ISO 21597 series and information modelling such as ISO 16739-1
and ISO 10303-239.
This document describes how to use various components of an IDM for verifiable and traceable execution
of digital communication. The resulting interaction framework enables standardization of digital
communication in construction processes within any collaboration within and between organizations.
As digital communication spans the entire life cycle of assets and occurs in projects of all sizes and
complexities, a standardized IT approach can benefit a wide range of stakeholders. Support for this standard
in various ICT solutions means that various information management systems are connected. By doing so, it
provides a basis for reliable information exchange and sharing for users, so that they can be confident that
the information they send or receive is accurate and sufficient for the coordination activities they need to
perform. This provides a basis for using common data environment (CDE) solutions and workflows.

v
International Standard ISO 29481-2:2025(en)
Building information models — Information delivery
manual —
Part 2:
Interaction framework
1 Scope
This document specifies a methodology for describing and managing interactions and a format for digital
communication between actors in any use case associated with the management of an asset during all life
cycle stages.
It provides:
— a methodology that describes an interaction framework for a use case;
— an appropriate way to map responsibilities and interactions that provides a process context for
information flow;
— a format in which the interaction framework is specified and executed.
This document is intended to promote secure, verifiable, traceable and high-quality digital IDM
communication between actors during all phases of the life cycle of assets, facilitate interoperability between
software applications used, and to provide a basis for data- and process-driven information exchange and
traceability of communication.
2 Normative references
The following documents are referred to in the text in such a way that some or all of their content constitutes
requirements of this document. For dated references, only the edition cited applies. For undated references,
the latest edition of the referenced document (including any amendments) applies.
ISO 29481-1, Building information modelling — Information delivery manual — Part 1: Methodology and format
ISO 14533-2, Processes, data elements and documents in commerce, industry and administration — Long term
signature — Part 2: Profiles for XML Advanced Electronic Signatures (XAdES)
3 Terms and definitions
For the purposes of this document, the terms and definitions given in ISO 29481-1 and the following apply.
ISO and IEC maintain terminology databases for use in standardization at the following addresses:
— ISO Online browsing platform: available at https:// www .iso .org/ obp
— IEC Electropedia: available at https:// www .electropedia .org/

ISO 29481-2:2025(en)
3.1 General
3.1.1
message
information prepared for communication purposes
[SOURCE: ISO 5127:2017, 3.1.8.02]
3.1.2
digital IDM communication
exchange of messages (3.1.1) within the confines of a use case enabled by an interaction framework and
project specific message (3.2.1)
3.2 Technical components
3.2.1
project specific message
PSM
structured file that places the interaction framework in the context of a specific project by linking roles to
persons and associated organizations
3.2.2
interaction framework schema
XML schema definition file used to validate an interaction framework
3.2.3
interaction message schema
XML schema definition file used to validate a message (3.1.1)
3.2.4
promotor
algorithm that generates an interaction framework schema (3.2.2) from an interaction framework, with the
support of a template definition (3.2.5) used as input
3.2.5
templates definition
file containing a number of templates, independent of the specific interaction framework, for generating an
interaction framework schema (3.2.2) and an interaction message schema (3.2.3)
4 Notation
The following notation conventions apply in this document:
— this document follows the notations used in ISO/IEC 23009-1 for describing elements in an XML document;
— primary element types are identified by an upper-case first letter as Element; if an element’s name
consists of two or more combined words, PascalCase is used, e.g. ImportantElement;
— secondary element types, attributes and references are identified by a lower-case first letter; if one of these
consists of two or more combined words, camelCase is used after the first word, e.g. importantAttribute;
— elements are graphically displayed as unified modelling language (UML) diagrams; this document
follows the graphic notations used in ISO 24156-1.

ISO 29481-2:2025(en)
5 Interaction framework
5.1 General
This clause explains the core concepts and principles for the development and use of an interaction
framework for digital IDM communication. By following the methodology presented in this document,
users of software tools can model (in a machine interpretable XML file) the business context and exchange
requirements of a specified use case and subsequently start to digitally communicate with each other based
on that interaction framework.
5.2 Information management and the interaction framework
Information management involves defining, producing, checking, and delivering information. Every team
member in any business activity interacts with information management to some extent. The importance
of documented responsibility and accountability in information management is crucial, because focusing
on good information management leads to better project outcomes. To be effective, there shall be a shared
understanding of the processes and the necessary information required for each step of their execution.
An IDM captures the business context associated with a use case and defines a detailed specification of
the information that a user fulfilling a particular role would need to provide at a particular stage within a
business process to create a product or deliver a service.
Generally speaking, a use case involves delivering goods or providing services to customers or clients. As
soon as a customer or client requests the delivery of a batch of goods or the provision of a service, a chain of
activities is set in motion to fulfil that request. Such a chain of activities is called a business context.
This leads to the basic framework of an IDM as illustrated in Figure 1. Each use case has an associated
business context and required information.

ISO 29481-2:2025(en)
Key
association
inheritance
aggregation
composition
Figure 1 — IDM Basic framework
The business context is usually represented in an IDM by any combination of interaction maps and process
maps, supported by textual representations or graphic information. The analysis of the business context
may be thought of as a discovery process using those two mapping approaches since their purpose is to
clearly show how the information exchange requirements for the use case are derived.
An exchange requirement provides a description of the information to be exchanged between roles in
natural language terms to support a particular business process in the relevant life cycle stage (within a
business context). An exchange requirement may support either (or both) the communication of information
essential to the design, construction, operation and deconstruction of an asset or it may support the
communication of management information with messages that control project execution in relation to the
life cycle management of the asset.
To deliver a service or produce a product within a use case, actors perform various activities. Taken in their
entirety, these form the business context. Often, within the business context there are chains of activities that
provide sub products or services, these are called business processes. At certain points in time, information
is needed by an actor to fulfil their task, or it is part of their responsibility to deliver specific information.
When this information is transferred from one actor to another, an interaction occurs. The receiving actor
determines if the information is complete and correct.

ISO 29481-2:2025(en)
An information exchange therefore is never a single activity, it is a (digital) conversation between two actors
to satisfy a specific information requirement.
This document focuses on formally structuring, recording and supporting these interactions and their
requirements to achieve an outcome. This is known as performative communication.
5.3 Purpose of an interaction framework
The interaction framework is the core of digital IDM communication. It is a formal technical XML description
that includes all elements necessary for interactions within use cases, such as roles, transactions, messages
in transactions, and data elements in messages. The scope of an interaction framework aligns with the scope
of a use case in an IDM.
Creating an interaction framework not only allows the identification of detailed information exchange
requirements but also facilitates (through compatible software) verifiable and traceable digital IDM
communication between participants during all phases of the life cycle of assets. When properly set up, an
interaction framework forms the foundation for software tools to enable users to communicate digitally
and purposefully through messages based on the processes, roles, exchange requirements, and information
defined by the IDM. Digital IDM communication through an interaction framework enables better process
control, improved data management, increased transparency, enhanced verifiability of agreements, and a
higher quality of the final product. A software tool utilizing an interaction framework structures, monitors,
and stores communication by providing a shared digital communication archive. It clarifies responsibilities
and decisions promptly, keeps project archives up-to-date and complete, facilitates faster and more flexible
partnerships, and prevents miscommunication.
Since the process and content resides in the machine-readable interaction framework rather than being
embedded in a software tool, a software solution implementing this method can support and improve
collaboration of any use case without specialized software.
It also ensures interoperability between software tools that support this document, facilitating seamless
messaging between applications. Every organization may freely choose software tools that implement the
interaction framework, ensuring secure messaging between them. This guarantees each party complete
access to mutual communication through their own chosen software while shielding internal communication
from the collaborating partners.
The basic principles, terms and concepts of the modelling of interactions that this document prescribes are
1)
based on design and engineering methodology for organizations (DEMO) .
DEMO is a method for analysing and (re)designing organizations, in which human action is central. DEMO
describes the structure of an organization, abstracted from the implementation. It describes what happens
or should happen rather than how it happens. The focus is on the essence of an organization: what the
organization does, not how it does it. A DEMO model describes a partnership, either within an organization
and across organizations. A DEMO model forms a consistent set of products, responsibilities, processes,
information and business rules and gives an overview of, and insight into, organizations.
5.4 Hierarchical structure of an interaction framework
5.4.1 General
An interaction framework incorporates all necessary digital interactions and roles to realize the purpose of
a use case. Figure 2 illustrates the hierarchy of definitions within this document. Each transaction defines
1) The methodology of DEMO originated from science and was developed at Maastricht University and Delft University
of Technology by prof. dr. Jan Dietz (Reference [11]). It builds on various theories including systems theory (Reference
[17]), philosophy of language (References [10] and [16]), communicative action (Reference [14]), data modelling
(Reference [15]) and ontologies (Reference [13]). In collaboration with universities in Antwerp (Belgium), Duisburg
(Germany), Bolzano (Italy), Luxembourg, Vienna (Austria), Lisbon and Madeira (Portugal), Prague (Czech Republic), St.
Gallen (Switzerland), San Jose (USA) and Tokyo (Japan). The latest version of the methodology (DEMO-4) was released
in 2020. The further development of the DEMO methodology is supported by the international Enterprise Engineering
Institute.
ISO 29481-2:2025(en)
a sequence of messages exchanged between two roles. A message is a digital form, including possible
attachments, comprising data elements, which are categorized as complex and simple elements. The
behaviour of simple elements is determined by its user defined type and element conditions.
Figure 2 — Interaction framework with the hierarchy of its components
5.4.2 Roles
When defining a use case, roles are assigned to responsibilities and tasks, not specific functions or positions
within an organization. This is because the same roles consistently appear in business contexts, but
individuals in different functions or positions may fulfil multiple roles or switch between them. For example,
actors may fulfil roles such as 'initiator', 'client', 'builder', or 'designer'. The name of the role is derived from
its primary activity, emphasizing the role's contribution within transactions.
A key principle is that actors with roles negotiate with authority and responsibility. Only actors can make
agreements, take decisions, pass judgments, and enter into contracts. Roles therefore have to fulfil certain
qualifications.
There is not always a one-to-one relationship between actors and roles. In some business processes, one
actor may assume multiple roles, while in others, several actors may share the same role. For instance, a
municipality can be both the initiator and the client, or a contractor for earthworks and an installation
company may both take on the role of builder. An actor may also fulfil different roles across different
business processes.
Every interaction framework includes defined roles to streamline responsibilities and tasks. This approach
ensures clear and effective collaboration, providing a structured method to manage various functions
efficiently within the business activity. Roles may also be reassigned if project members leave, and
authorizations may be granted so others may take over their work. The audit trail always remains intact,
allowing visibility about who did what and when.

ISO 29481-2:2025(en)
5.4.3 Transactions
5.4.3.1 General
Each interaction framework consists of one or more transactions, defined by the use case and the associated
business context. In an interaction framework a transaction is a sequence of messages between two roles.
As shown in Figure 3, each transaction has an initiator (the role that starts the transaction) and an executor
(the role that carries out the transaction).
Figure 3 — A transaction always involves only two roles
Using transactions within information management brings information transfer into a process context. This
ensures that information is exchanged systematically and purposefully within a structured digital process.
Organizations using an interaction framework transition from document-driven to data-driven workflows
by digitally managed information and processes.
5.4.3.2 Business process scenarios and sub transactions
Depending on the business context and use case, an interaction framework may contain one or several
transactions. Within the business context, multiple transactions between roles are sometimes required in
sequence to achieve a goal. For example, when a role in transaction A prepares information that another role
in transaction B must review. In such cases, transactions shall be linked, forming a workflow known as a
business process scenario.
In a business process scenario, there is always a main transaction where the initial request is made linked to
one or more sub transactions. Sub transactions are designed to cascade from the main transaction. This is
detailed in 6.3.2.10.
5.4.3.3 Interaction map
2)
All necessary roles, transactions and sub transactions of a use case are described by the interaction map in
an IDM. This is an abstract representation that defines the boundary of a use case and highlights the essential
communication chain required to fulfil its purpose. The name is derived from the fact that it records the
interaction between the actors, i.e. their direct mutual influence. It leaves out all the activities and various
process steps. The use of abstract roles makes the interaction map applicable to various situations. Figure 4
shows a simplified example of an interaction map for a design office use case.
2) In DEMO terms the interaction map is called a coordination structure diagram.

ISO 29481-2:2025(en)
Figure 4 — Example of an interaction map of a design office use case
All roles and transactions in the interaction map have a unique identity and name, with numbering being
arbitrary. Roles are named based on their primary activities, emphasizing their contributions to the use
case. A composite role consists of multiple roles, but its composition is not relevant to the use case's scope.
5.4.3.4 Transaction product table
Each transaction has an intended result, also referred to as the product of that transaction. Together with
the transactions and roles described by the interaction map, this can be summarized in a transaction
product table. This table records the transaction kind (the name and unique number of each transaction),
the product kind (the product of each transaction) and its initiating and executing roles. See Table 1 for an
example.
Table 1 — Transaction product table of a simplified design office use case
Product kind Transaction kind Initiator role Executor role
Design is delivered T , Deliver design CR Client R Project leading
1 1 1
System specification is deliv- T , Deliver system specifica- R Project leading R System engineering
2 1 2
ered tion
3D model is delivered T , Deliver 3D model R Project leading R 3D engineering
3 1 3
Cost calculation is delivered T , Deliver cost calculation R Project leading R Cost engineering
4 1 4
5.4.4 Messages
5.4.4.1 General
To realize the product of a transaction, interactions take place between two roles. In the digital world, these
interactions are performed by means of digital messages. A transaction contains a set of messages that are
exchanged for a specific purpose. The transaction also specifies the participating roles, the point in the life
cycle, and the sequence in which messages should be delivered (if applicable).

ISO 29481-2:2025(en)
In terms of the IDM methodology, a message may carry information that satisfies the exchange requirement.
This information may consist of textual values entered directly into the message, or of attachments.
Attachments may be of any type, including structured information containers such as IFC files or information
container for linked document delivery (ICDD) and unstructured information containers such as documents,
spreadsheets, images, video files, and drawings. The interaction framework message also supports the
inclusion of metadata, such as version number, document date, and status. For certain message types, it may
be mandated that at least one attachment shall be added, and specific attachment types may be enforced by
the interaction framework.
5.4.4.2 Sequence of messages
Sets of messages in a transaction form a chain with a beginning and an end. Most process diagrams provide
an "ideal flow”, the best-case scenario of communicative actions where both actors fulfil their role without
dispute. However, in practice, processes rarely follow this ideal flow because humans can make mistakes, so
all possible outcomes should be considered, such as the need for adjustments or scenarios where a model is
not approved.
For example, a transaction involving a request for a 3D model (see Figure 5) illustrates a message sequence
in a transaction as a sequence diagram in UML notation. The transaction is initiated by R project leader
with the message 'Request for 3D model.' The 3D engineer (role R3) responds with 'Work done and request
for approval.' After a message 'Work approved' or 'Work not approved,' the transaction is completed.
The start message has no preceding message, being the only way to distinguish it from the other messages.
Similarly, the final message has no following message. Each message has a direction indicated by the labelled
arrow. A message may have several previous messages, e.g. a message approval may follow a delivery, but
also a renewed delivery. Similarly, the final message may contain both a reject and an approval. Therefore,
the chain of messages is not linear, but rather a mathematical graph.
Figure 5 — Example of messages in a transaction

ISO 29481-2:2025(en)
5.4.5 Complex and simple elements
A message is essentially a 'form' with data fields and attachments where required. Each message has
a header with details of the involved roles and the date and time the message was sent. The body of the
message includes the information to be transferred, such as: text fields, dates, amounts, yes/no, list boxes,
and tables. During digital IDM communication the data in the fields is stored in the database of the software
that executes it.
Each data field in a message is called a “simple element”, which is always part of a group called a “complex
element”. Each complex element may contain one or more simple elements. Simple elements may be made
mandatory or optional for users to fill in within a message. Each message shall contain at least one complex
element with at least one simple element, although a simple element may be empty. To create a table a
complex element shall be nested within another complex element.
The behaviour, restrictions (e.g. minimum length) and validation of simple elements are determined by their
UserDefinedType. During digital IDM communication inheritance takes place. In principle, data entered in a
simple element in a previous message are sent in a subsequent message, unless a so-called element condition
has been included in the interaction framework.
See Figure 6 for an example of complex and simple elements in the message “Proposal request for change.”
Figure 6 — Example of complex and simple elements within a message
There is no rule about which data fields should be included in a message and which data should be in
attachments created with other software tools. Depend
...