SIST EN ISO 29481-2:2016

SLOVENSKI STANDARD
01-december-2016
,QIRUPDFLMVNLPRGHOLVWDYE3ULURþQLN]LQIRUPDFLMDPLGHO2NYLUQLSRGDWNLR
PHGVHERMQHPYSOLYDQMX,62
Building information models - Information delivery manual - Part 2: Interaction framework
(ISO 29481-2:2012)
BIM - Informationshandbuch - Teil 2: Interaktionsstruktur (ISO 29481-2:2012)
Modèles des informations de la construction - Contrat d'interchange - Partie 2: Cadre
d'interaction (ISO 29481-2:2012)
Ta slovenski standard je istoveten z: EN ISO 29481-2:2016
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
October 2016
EUROPÄISCHE NORM
ICS 91.010.01
English Version
Building information models - Information delivery
manual - Part 2: Interaction framework (ISO 29481-
2:2012)
Modèles des informations de la construction - Contrat BIM - Informationshandbuch - Teil 2:
d'interchange - Partie 2: Cadre d'interaction (ISO Interaktionsstruktur (ISO 29481-2:2012)
29481-2:2012)
This European Standard was approved by CEN on 30 September 2016.

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, Former Yugoslav Republic of Macedonia, France, Germany, Greece, Hungary, Iceland, Ireland, Italy, Latvia, Lithuania,
Luxembourg, Malta, Netherlands, Norway, Poland, Portugal, Romania, Slovakia, Slovenia, Spain, Sweden, Switzerland, Turkey and
United Kingdom.
EUROPEAN COMMITTEE FOR STANDARDIZATION
COMITÉ EUROPÉEN DE NORMALISATION

EUROPÄISCHES KOMITEE FÜR NORMUNG

CEN-CENELEC Management Centre: Avenue Marnix 17, B-1000 Brussels
© 2016 CEN All rights of exploitation in any form and by any means reserved Ref. No. EN ISO 29481-2:2016 E
worldwide for CEN national Members.

Contents Page
European foreword . 3

European foreword
The text of ISO 29481-2:2012 has been prepared by Technical Committee ISO/TC 59 “Buildings and
civil engineering works” of the International Organization for Standardization (ISO) and has been taken
over as EN ISO 29481-2:2016 by 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 April 2017, and conflicting national standards shall be
withdrawn at the latest by April 2017.
Attention is drawn to the possibility that some of the elements of this document may be the subject of
patent rights. CEN [and/or CENELEC] shall not be held responsible for identifying any or all such patent
rights.
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, Former Yugoslav Republic of Macedonia,
France, Germany, Greece, Hungary, Iceland, Ireland, Italy, Latvia, Lithuania, Luxembourg, Malta,
Netherlands, Norway, Poland, Portugal, Romania, Slovakia, Slovenia, Spain, Sweden, Switzerland,
Turkey and the United Kingdom.
Endorsement notice
The text of ISO 29481-2:2012 has been approved by CEN as EN ISO 29481-2:2016 without any
modification.
INTERNATIONAL ISO
STANDARD 29481-2
First edition
2012-12-15
Building information models —
Information delivery manual —
Part 2:
Interaction framework
Modèles des informations de la construction — Contrat
d’interchange —
Partie 2: Cadre d’interaction
Reference number
ISO 29481-2:2012(E)
©
ISO 2012
ISO 29481-2:2012(E)
© ISO 2012
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 copyright@iso.org
Web www.iso.org
Published in Switzerland
ii © ISO 2012 – All rights reserved

ISO 29481-2:2012(E)
Contents Page
Foreword .iv
Introduction .v
1 Scope . 1
2 Normative references . 1
3 Terms and definitions . 1
4 Standard principles . 2
4.1 General . 2
4.2 BIM and IDM . 2
4.3 Components of IDM . 2
4.4 Basic principles of business communication . 3
4.5 Interaction map . 4
4.6 Messages in transaction . 6
4.7 Interaction framework . 6
4.8 Supporting the software solutions . 7
5 Format of an interaction framework . 9
5.1 Introduction . 9
5.2 Information types in the interaction framework schema . 9
Annex A (normative) Interaction framework schema definition .12
Annex B (normative) Templates definition .43
Annex C (informative) Example interaction map of a simplified design office .61
Annex D (informative) Principles for Promotor algorithm .73
Bibliography .74
ISO 29481-2:2012(E)
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 part of ISO 29481 may be the
subject of patent rights. ISO shall not be held responsible for identifying any or all such patent rights.
ISO 29481-2 was prepared by Technical Committee ISO/TC 59, Buildings and civil engineering works,
Subcommittee SC 13, Organization of information about construction works.
ISO 29481 consists of the following parts, under the general title Building information models —
Information delivery manual:
— Part 1: Methodology and format
— Part 2: Interaction framework
The following parts are under preparation:
— Part 3: Model view definitions
iv © ISO 2012 – All rights reserved

ISO 29481-2:2012(E)
Introduction
Building information modelling provides a concept for describing and displaying information required
in the design, construction, and operation of constructed facilities. It can bring together the diverse sets
of information used in construction into a common information environment — reducing, and often
eliminating, the need for the many types of paper documentation currently in use.
An information delivery manual (IDM) provides significant help in getting the full benefit from a building
construction information model (BIM). If the information required is available when it is needed and the
quality of information is satisfactory, the construction process itself will be greatly improved. For this to
happen, there should be a common understanding of the building processes and of the information that
is needed for and results from their execution.
This part of ISO 29481 focuses on aspects of the construction process that refer to management and
coordination of the involved parties. Coordination is dependent on communication, which should be well
structured, unambiguous, explicit, and prompt. Due to a sharp focus on coordination and interaction,
this part of ISO 29481 provides a natural complement to standards that focus on building modelling like
ISO 10303-239 and ISO 16739.
This part of ISO 29481 sets out a methodology and format for describing coordination acts between
actors in a construction project. It describes how to identify and define the coordination processes
undertaken and the information required for their execution. The resulting interaction frameworks
enable standardization of interaction in building processes on national, local, and project level. It also
gives a format to support solutions provided by ICT-solution providers. Support of this part of ISO 29481
in different ICT-solutions means that this joins together different process management systems. In doing
so, it provides a basis for reliable information exchange/sharing for users, so that they can be confident
that the information they are sending or receiving is accurate and sufficient for the coordination
activities they need to perform.
The development of this part of ISO 29481 has been driven by the need of users for reliability in
information exchange. It is mainly based on the Dutch VISI standard developed in 2003.
INTERNATIONAL STANDARD ISO 29481-2:2012(E)
Building information models — Information delivery
manual —
Part 2:
Interaction framework
1 Scope
This part of ISO 29481 specifies a methodology and format for describing ‘coordination acts’ between
actors in a building construction project during all life cycle stages.
It therefore specifies
— a methodology that describes an interaction framework,
— an appropriate way to map responsibilities and interactions that provides a process context for
information flow,
— a format in which the interaction framework should be specified.
This part of ISO 29481 is intended to facilitate interoperability between software applications used in
the construction process, to promote digital collaboration between actors in the building construction
process, and to provide a basis for accurate, reliable, repeatable, and high-quality information exchange.
2 Normative references
The following documents, in whole or in part, are normatively referenced in this document and are
indispensable for its application. 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
3 Terms and definitions
For the purposes of this document, the following terms and definitions apply.
3.1
IDM
Information Delivery Manual
documentation which captures the business process and gives detailed specifications of the information
that a user fulfilling a particular role would need to provide at a particular point within a project
3.2
interaction framework
formal description of the elements of interaction, including definition of roles, transactions, messages in
transaction, and data elements in messages
3.3
interaction framework schema
formal description of the rules with which an interaction framework must comply
ISO 29481-2:2012(E)
3.4
interaction schema
formal description of the rules with which sent and received messages must comply
3.5
promotor
algorithm that generates an interaction schema from an interaction framework, interaction framework
schema, and templates file as input
3.6
templates file
file containing a number of templates, independent of the interaction framework, for generating an
interaction schema
3.7
VISI
acronym for Dutch standard for communication between partners in construction projects
Note 1 to entry: VISI stands for “Voorwaarden scheppen voor Invoeren Standaardisatie ICT in de Infrastructuur-
sector” which translates as “Creating conditions for the implementation of ICT standardization for the
construction industry”)
4 Standard principles
4.1 General
This clause is included to highlight and help explain essential concepts on which this part of
ISO 29481 is based.
4.2 BIM and IDM
Building information modelling brings together the diverse sets of information used in construction
into a common information environment. For this to happen, there should be a common understanding
of the building processes and the information that is needed for and from their execution.
ISO 29481 is a standard that sets out a method for the development of an Information Delivery Manual.
The IDM methodology given in ISO 29481-1 shall be used for all references to development and use of IDM.
4.3 Components of IDM
The methodology and components of IDM are described in ISO 29481-1. In that part, an illustration is
given that diagrammatically shows what the different components of IDM are and how they are related.
Within IDM, there are two perspectives. These are seen as user requirements and technical solutions.
Within the two perspectives, there are a number of zones that characterize the various components of
IDM (see Figure 1).
2 © ISO 2012 – All rights reserved

ISO 29481-2:2012(E)
Figure 1 — IDM zones
Within the user-requirements perspective, these zones are
— interaction maps, describing the roles and interactions between them,
— process maps, describing the overall process in which information exchange occurs,
— information delivery, describing the information exchange needs,
— reference processes (stored exchange descriptions),
— the project schedule (occurrences of processes in the context of a project).
The technical-solution perspective includes
— the business objects comprising the exchange requirement model,
— the information specification, describing the schema on which the information exchange is based,
— the building information model.
This part of ISO 29481 focuses on the interaction map and is based on general principles of business
communication.
4.4 Basic principles of business communication
Once a client or customer has asked to deliver a product or provide a service, there will be a chain
of activities in operation, whose combined effect is to provide the product or service. Such a chain of
activities is called a business process. More specifically, we speak here of a primary business process
because it is initiated externally.
Part of the business process is the communication between the involved parties. This part of
ISO 29481 concentrates on the communication that relates to the delivery of an outcome (performative
communication). The initiation and execution of a request is through communicative actions. In a
communicative action, two parties are always involved: the person who performed the action and the
person to whom the action is directed. The handling of a request appears to occur in a particular pattern
called the transaction.
ISO 29481-2:2012(E)
Figure 2 — A transaction pattern (Dietz, 2006)
In Figure 2, the simplest form of this transaction pattern is presented. It shows that bringing about
of a new production result (for example, the ‘desired result’ is the delivery of a document) starts with
requesting of this result by someone in the role of customer from someone in the role of producer. This
brings the process to the state “result requested”. The producer responds to the request by promising
to produce the desired result, which brings the process to the state “result promised”. This presents a
to-do item for the producer: he has to comply with the promise by actually preparing the document and
deciding to deliver the document. In the act of handing over the document to the customer, he states
that he has complied with his promise. The customer responds to this state by accepting the result as
produced. This act completes the transaction.
In the execution of the business process, often many actors are involved. Their behaviour is dependent
on their role in the process. Roles/actors do business with other roles/actors by executing transactions.
A useful representation of the interaction between roles/actors is called the interaction map.
4.5 Interaction map
An interaction map shall identify the relevant role types and transaction types for a certain process.
IDM draws a distinction between a role that makes a request, the initiator, and the role that gives effect
to that request, the executor. A transaction shall have only one initiating role and only one executing
role. Figure 3 shows the components of the interaction map.
NOTE The notation of the interaction map is based on the construction model as described in the publication
of Prof. Jan L.G. Dietz. This notation differs from BPMN and is used to prepare maps that are as simple as possible.
Also, it provides the concept of ‘transaction’, which is not available in BPMN.
4 © ISO 2012 – All rights reserved

ISO 29481-2:2012(E)
R CR
j j
Role type R Composite Boundary, scope of
j
Role type CR interacon
j
T
j
Transacon type T Iniator link Executor link
j
Figure 3 — Components of the interaction map
The advantage of the interaction map is that it focuses attention on the interfaces between roles
while hiding the complexity of the process within the domain of the roles and hiding the details of
the interaction between the roles. The use of abstract roles makes the interaction map valid for many
different situations. The interaction map is a valuable tool for analysing and defining essential elements
of a business process. Figure 4 shows a simplified example of an interaction map of a design office.
Design office
CR R
1 2
T T
Project System
Client leading engineering
R R
1 3
T
3D
engineering
R
T
Cost
engineering
Figure 4 — Example of an interaction map
In an interaction map, all transactions needed for the handling of required contributions of relevant
roles to the BIM shall be included. All roles and transactions within the interaction map shall have a
unique identity and name. The numbering is arbitrary. The name of the role is derived from the main
activity undertaken by the role; this brings focus on the contribution of the role to the BIM. A composite
role is a role which may consist of multiple roles but whose composition is unknown or not relevant.
The interactions can be summarized in a transaction table.
ISO 29481-2:2012(E)
Table 1 — Transaction table of a simplified design office
Transaction result Transaction type
Design is delivered T , Deliver design
System specification is delivered T , Deliver system specification
3D model is delivered T , Deliver 3D model
Cost calculation is delivered T , Deliver cost calculation
4.6 Messages in transaction
A transaction shall contain a set of messages that are exchanged for a particular purpose. The transaction
also stipulates the participating roles, point in the life cycle, and the sequence in which messages should
be delivered (if appropriate).
An example of a transaction is the handling of a request for a 3D model. See Figure 5, which shows the
messages in a transaction as a sequence diagram in UML notation. The transaction can only be initiated
by R1 Project leading with the message ‘Request for 3D model’. The 3D engineer (role R3) can respond
with a message ‘Work done and request for approval’. After a message ‘Work approved’ or ‘Work not
approved’, the transaction is completed.
R : Project leading R : 3D Engineering
1 3
Request for3D model
Work done and request approval
Request adjustments
Work approved
Work notapproved
Transacon: T₃ –Request for3D model
Figure 5 — Example of messages in a transaction
A message is a populated information model and contains data. Attachments may be linked to messages.
As an attachment, an exchange requirement can be transferred to the executing role, and the result
(contribution to the BIM) is delivered to the initiating role. By using transactions, the information
transfer is brought in a process context.
4.7 Interaction framework
In order to give guidance to a process and information transfer, the elements of interaction need to
be described in a coherent manner. This coherent description is called an interaction framework. An
interaction framework shall include
— definition of relevant roles,
— transactions,
6 © ISO 2012 – All rights reserved

ISO 29481-2:2012(E)
— messages in transaction,
— the order of messages in transaction,
— data elements in messages.
An interaction framework can be prepared for a defined application area and used as a standard on
(inter-)national level, organization level, or project level. For example, in the Netherlands, an interaction
framework is developed at the national level for the completion of all contractual procedures during the
execution of a construction project. This part of ISO 29481 is used as a template by organizations and
projects and adjusted to specific needs.
EXAMPLE An interaction framework may include the attribute CostEstimation as an instance of
SimpleElementType to be used as a mandatory element for a certain message. It also may include a restriction on
the format of the attribute CostEstimation (e.g. only euros with two decimals).
4.8 Supporting the software solutions
4.8.1 Overview
The next step is to support the interaction framework with software solutions. The aim is
— to support the editing of an interaction framework,
— to guarantee the completeness and validity of an interaction framework,
— to support the portability of an interaction framework,
— to support the operation of information systems,
— to support the interoperability of communication.
In the support of software solutions, two levels can be identified. The first level concerns the interaction
framework. The second level concerns the actual communication which is based on the interaction
framework. This part of ISO 29481 applies to both levels.
An overview on how the software solutions are supported is given in Figure 6. The following sections
provide an explanation.
4.8.2 Supporting the interaction framework
In order to support the portability of an interaction framework, it should be clear with which rules an
interaction framework must comply. These rules shall be included in an interaction framework schema,
which is recorded as an XSD schema file. An interaction framework comprises instances of classes
defined in the schema and shall be recorded as an XML file.
EXAMPLE The interaction framework schema defines that you may include the definition of attributes
(SimpleElementType) and restrictions to attributes (UserdefinedType) in an interaction framework.
Chapter 5 describes the interaction framework schema and the available classes.
Every interaction framework should comply with the interaction framework schema.
An interaction framework editor should use the interaction framework schema to validate the
produced frameworks.
4.8.3 Promotor
Once a valid interaction framework is available, it can be interpreted by a suitable information system.
Then this system can support the communications in accordance with the options set out in the
interaction framework. Finally, it is desirable to be able to validate the received and sent messages; this
is done with the interaction schema.
ISO 29481-2:2012(E)
The interaction schema is generated with a generic algorithm called Promotor. The Promotor ‘promotes’
XML instances tot XSD classes. The input is
— interaction framework (XML),
— interaction framework schema (XSD),
— templates file (XSD), containing a number of templates not described in an interaction framework
but are valid for every interaction schema, for example the message header.
The output is an interaction schema recorded as an XSD file.
EXAMPLE The ‘Promotor’ takes information from the interaction framework to include the attribute
CostEstimation to be used as a mandatory element for a certain message and creates an interaction schema which
defines the message with the CostEstimation attribute.
Annex B describes the templates XSD file.
Annex D gives the principles of the Promotor.
Interaction framework
Schema(XSD)
Create interaction
framework
Templates (XSD)
Interaction
framework(XML)
Promote XML
instances to XSD
classes
Create/send
message
Interaction
schema(XSD)
Message (XML)
Receive/read
message
Interaction
schema(XSD)
Figure 6 — How software solutions are supported
4.8.4 Supporting communication
Every information system that participates in the communication, as defined in the interaction
framework, should operate on the basis of the corresponding interaction framework and interaction
schema. Every message that is sent or received should be valid according to the interaction schema.
8 © ISO 2012 – All rights reserved
Transaction executor Transaction initiator Promoter Interaction framework designer

ISO 29481-2:2012(E)
4.8.5 Technical implementation of communication
In order to ensure that messages with attachments in technical sense can be exchanged between
information systems, there is a need for implementation guidelines. Topics to be covered include
— communication protocol,
— communication architecture/servers,
— encryption,
— SOAP function calls.
Implementation guidelines are beyond the scope of this part of ISO 29481.
5 Format of an interaction framework
5.1 Introduction
Clause 4 explains that, in order to support software solutions, every interaction framework must comply
with the interaction framework schema. This clause is included to define the format of an interaction
framework through a description of the interaction framework schema.
5.2 provides an overview of the information classes that can occur in an interaction framework and are
defined in the interaction framework schema. Since an interaction framework is defined in XML, the
word ‘type’ is used rather than class. Annex A gives the full description of the interaction framework
schema. Annex C provides an example of an instance of an interaction framework.
5.2 Information types in the interaction framework schema
5.2.1 Introduction
A schema is populated by many classes or types. In this section, a short description is given of the
available types in the interaction framework schema. Annex A contains a full description in XML of the
interaction framework schema. An interaction framework shall be created from instances of these types
and shall have a header which points to the schema with the defined available types.
5.2.2 AppendixType
The AppendixType is a definition to define the structure of elements regarding metadata. An instance
of an AppendixType is used to define certain types of files or documents which can be part of the
send/received messages. The structure of the elements related to an instance of an AppendixType
represents the specific metadata which is required for a certain type of file or document.
5.2.3 ComplexElementType
A ComplexElementType is a collection of SimpleElementTypes. Every SimpleElementType occurs exactly
the number of times it is related to.
5.2.4 ElementCondition
An instance of an ElementCondition describes the behaviour of element values in successive messages.
For example, when an instance of the type ElementCondition is created with the value FIXED, it indicates
that elements in successive messages must be copied when the same element is available and the value
cannot be changed. An ElementCondition can refer to different levels in a framework. It can be directly
related to a SimpleElement but it is also possible to relate an ElementCondition to a ComplexElement or
a MessageInTransactionType. In this case, the ElementCondition is valid for all elements which are part
of the element structure/collection of the related types.
ISO 29481-2:2012(E)
5.2.5 GroupType
A GroupType makes it possible to create multiple instances of a group with their own specific content.
The GroupType can be used to categorize messages within a transaction or documents related to
messages within a transaction.
5.2.6 MessageType
The MessageType is used to define the content of a message. The elements that are part of a message are,
in turn, grouped into one or more instances of a ComplexElementType.
5.2.7 MessageInTransactionType
The MessageInTransactionType (MITT) is a definition which is used to relate MessageType’s to
TransactionType’s. Or simply said: the same message type may occur more than once in a given
transaction type and vice versa. It is possible to relate more of the same instance of a MessageType
to one instance of a TransactionType and one instance of a MessageType to multiple instances of a
TransactionType. Besides, a MITT offers an option to reverse the direction from executor to initiator.
Another option controls if the message flow is blocked by open secondary transactions or not.
5.2.8 OrganisationType
Definition of a certain group of organizations. In common, at least one instance is available in the
framework with the particular reason to define the structure of elements of an organization.
5.2.9 PersonType
Definition of a type of person. In common, at least one instance is available in the framework with the
particular reason to define the structure of elements to define a person. The PersonType can be used to
categorize groups of persons who are related to a role.
5.2.10 ProjectType
Definition of a type of project. In common, at least one instance is available in the framework with the
particular reason to define the structure of elements to define the project.
5.2.11 RoleType
Definition of a role. Instances of a RoleType are prerequisites to create a TransactionType in a framework.
5.2.12 SimpleElementType
The SimpleElementType is a definition which describes properties which can occur within object
structures. The relation to an object is always via a ComplexElementType.
5.2.13 TransactionPhaseType
Definition which can be used to define an instance which describes the phase a transaction is in. For
example, an instance of a TransactionPhaseType can be “result requested” or “on hold”.
5.2.14 TransactionType
Definition of a transaction. In an instance of a Transaction, the roles of the initiator and executor are defined.
5.2.15 UserDefinedType
The UserDefinedType is used to set data types (for example, a string) and XSD restrictions. For example,
with an instance of a UserDefinedType, the minimal length of a string can be defined.
10 © ISO 2012 – All rights reserved

ISO 29481-2:2012(E)
Figure 7 visualizes the model of the interaction framework schema, including all its references.
Figure 7 — Types and references of the interaction framework schema
ISO 29481-2:2012(E)
Annex A
(normative)
Interaction framework schema definition
A.1 Introduction
An interaction framework must comply with the rules that are included in an interaction framework
schema. In this annex, the interaction framework schema definition is given in EXPRESS format and in
XSD format. Also, descriptions are given of Element types, attributes, elements, and references.
All objects in an interaction framework require a start date and end date. This requirement is to enable
time constraints to the validity of a certain object.
A.2 Interaction framework schema definition (EXPRESS format)
SCHEMA ISO 29481_Part_2A;
ENTITY ProjectType; — The definition of a specific group of projects. Generally, only
one instance will be present in an interaction framework defining the structure of elements that each
instance of project should expose.
namespace: STRING;
description: STRING;
startDate: DATETIME;
endDate: DATETIME;
state: STRING;
dateLaMu: DATETIME;
userLaMu: STRING;
language: OPTIONAL STRING;
category: OPTIONAL STRING;
helpInfo: OPTIONAL STRING;
code: OPTIONAL STRING;
complexElements: OPTIONAL SET [0:?] OF ComplexElementType;
END_ENTITY;
ENTITY PersonType; — The definition of a specific group of persons. Generally, only
one instance will be present in an interaction framework defining the structure of elements that each
instance of person should expose.
description: STRING;
startDate: DATETIME;
endDate: DATETIME;
12 © ISO 2012 – All rights reserved

ISO 29481-2:2012(E)
state: STRING;
dateLaMu: DATETIME;
userLaMu: STRING;
language: OPTIONAL STRING;
category: OPTIONAL STRING;
helpInfo: OPTIONAL STRING;
code: OPTIONAL STRING;
complexElements: OPTIONAL SET [0:?] OF ComplexElementType;
END_ENTITY;
ENTITY OrganisationType; — The definition of a specific group of organizations. Generally, only
one instance will be present in an interaction framework defining the structure of elements that each
instance of organization should expose.
description: STRING;
startDate: DATETIME;
endDate: DATETIME;
state: STRING;
dateLaMu: DATETIME;
userLaMu: STRING;
language: OPTIONAL STRING;
category: OPTIONAL STRING;
helpInfo: OPTIONAL STRING;
code: OPTIONAL STRING;
complexElements: OPTIONAL SET [0:?] OF ComplexElementType;
END_ENTITY;
ENTITY AppendixType; — An AppendixType contains the definition of an appendix. Which
data items should be recorded with an appendix can be specified in the complex element section.
description: STRING;
startDate: DATETIME;
endDate: DATETIME;
state: STRING;
dateLaMu: DATETIME;
userLaMu: STRING;
language: OPTIONAL STRING;
category: OPTIONAL STRING;
ISO 29481-2:2012(E)
helpInfo: OPTIONAL STRING;
code: OPTIONAL STRING;
complexElements: OPTIONAL SET [0:?] OF ComplexElementType;
END_ENTITY;
ENTITY ComplexElementType; — A ComplexElementType contains a set of
SimpleElementTypes. Each stated SimpleElementType occurs exactly the number of times it is mentioned.
description: STRING;
startDate: DATETIME;
endDate: DATETIME;
state: STRING;
dateLaMu: DATETIME;
userLaMu: STRING;
language: OPTIONAL STRING;
category: OPTIONAL STRING;
helpInfo: OPTIONAL STRING;
complexElements: OPTIONAL SET [0:?] OF ComplexElementType;
simpleElements: OPTIONAL SET [0:?] OF SimpleElementType;
END_ENTITY;
ENTITY MessageType; — The definition of a type of message (MessageType), specifying the structure
of the message and which set of SimpleElementType’s (via ComplexElementType’s) may accompany.
description: STRING;
startDate: DATETIME;
endDate: DATETIME;
state: STRING;
dateLaMu: DATETIME;
userLaMu: STRING;
language: OPTIONAL STRING;
category: OPTIONAL STRING;
helpInfo: OPTIONAL STRING;
code: OPTIONAL STRING;
complexElements: OPTIONAL SET [0:?] OF ComplexElementType;
appendixTypes: OPTIONAL SET [1:?] OF AppendixType;
END_ENTITY;
14 © ISO 2012 – All rights reserved

ISO 29481-2:2012(E)
ENTITY ElementCondition; — The condition of a SimpleElementType as used within a specific
MessageType.
description: STRING;
condition: STRING;
helpInfo: OPTIONAL STRING;
complexElement: OPTIONAL ComplexElementType;
simpleElement: OPTIONAL SimpleElementType;
messageInTransaction: OPTIONAL MessageInTransactionType;
END_ENTITY;
ENTITY SimpleElementType; — The definition of a simple element type (SimpleElementType).
This element type specifies a property which may occur within various object structures, for
example in MessageType (see also AppendixType, ProjectType, PersonType, and OrganisationType). A
SimpleElementType is always embedded in a ComplexElementType.
description: STRING;
interfaceType: STRING;
state: STRING;
dateLaMu: DATETIME;
userLaMu: STRING;
language: OPTIONAL STRING;
category: OPTIONAL STRING;
helpInfo: OPTIONAL STRING;
valueList: OPTIONAL STRING;
userDefinedType: UserDefinedType;
END_ENTITY;
ENTITY UserDefinedType; — A specification of a data type (to be used in a SimpleElementType).
This data type encapsulates fill-in areas in the final message, for example a Dutch zip code starts always
with four digits and then two characters.
description: STRING;
state: STRING;
dateLaMu: DATETIME;
userLaMu: STRING;
baseType: STRING;
xsdRestriction: OPTIONAL STRING;
language: OPTIONAL STRING;
helpInfo: OPTIONAL STRING;
END_ENTITY;
ISO 29481-2:2012(E)
ENTITY MessageInTransactionType; — The occurrence of a MessageType within a TransactionType
related to a certain group type (GroupType).
requiredNotify: INTEGER;
dateLaMu: DATETIME;
userLaMu: STRING;
received: BOOLEAN;
send: BOOLEAN;
state: STRING;
initiatorToExecutor: OPTIONAL BOOLEAN;
openSecondaryTransactionsAllowed: OPTIONAL BOOLEAN;
firstMessage: OPTIONAL BOOLEAN;
message: MessageType;
previous: OPTIONAL SET [0:?] OF MessageInTransactionType;
transaction: TransactionType;
transactionPhase: OPTIONAL TransactionPhaseType;
group: GroupType;
appendixTypes: OPTIONAL SET [1:?] OF AppendixType;
END_ENTITY;
ENTITY TransactionPhaseType; — The definition of a phase related to a transaction.
Examples are ‘assignment accepted’ or ‘result part received’.
description: STRING;
startDate: DATETIME;
endDate: DATETIME;
state: STRING;
dateLaMu: DATETIME;
userLaMu: STRING;
language: OPTIONAL STRING;
category: OPTIONAL STRING;
helpInfo: OPTIONAL STRING;
code: OPTIONAL STRING;
END_ENTITY;
ENTITY TransactionType; — The definition of a type of transaction. A transaction type may
reference other transaction types. A transaction will be initiated by a person belonging to an organization
fulfilling a certain role. At this level, the role type of the initiator should be stated (the promoted schema
will enforce this). The same holds for the executor.
16 © ISO 2012 – All rights reserved

ISO 29481-2:2012(E)
description: STRING;
startDate: DATETIME;
endDate: DATETIME;
state: STRING;
dateLaMu: DATETIME;
userLaMu: STRING;
language: OPTIONAL STRING;
category: OPTIONAL STRING;
helpInfo: OPTIONAL STRING;
code: OPTIONAL STRING;
result: OPTIONAL STRING;
subTransactions: OPTIONAL SET [1:?] OF TransactionType;
initiator: RoleType;
executor: RoleType;
appendixTypes:
...