ISO/IEC 14478-2:1998
(Main)Information technology — Computer graphics and image processing — Presentation Environment for Multimedia Objects (PREMO) — Part 2: Foundation Component
Information technology — Computer graphics and image processing — Presentation Environment for Multimedia Objects (PREMO) — Part 2: Foundation Component
Technologies de l'information — Infographie et traitement d'images — Environnement de présentation d'objets multimédia (PREMO) — Partie 2: Composant fondamental
General Information
Relations
Standards Content (Sample)
INTERNATIONAL ISO/IEC
STANDARD 14478-2
First edition
1998-12-15
Corrected and reprinted
2000-09-15
Information technology — Computer
graphics and image processing —
Presentation Environment for Multimedia
Objects (PREMO) —
Part 2:
Foundation Component
Technologies de l'information — Infographie et traitement d'images —
Environnement de présentation d'objects multimédia (PREMO) —
Partie 2: Composant fondamental
Reference number
©
ISO/IEC 1998
PDF disclaimer
This PDF file may contain embedded typefaces. In accordance with Adobe's licensing policy, this file may be printed or viewed but shall not
be edited unless the typefaces which are embedded are licensed to and installed on the computer performing the editing. In downloading this
file, parties accept therein the responsibility of not infringing Adobe's licensing policy. The ISO Central Secretariat accepts no liability in this
area.
Adobe is a trademark of Adobe Systems Incorporated.
Details of the software products used to create this PDF file can be found in the General Info relative to the file; the PDF-creation parameters
were optimized for printing. Every care has been taken to ensure that the file is suitable for use by ISO member bodies. In the unlikely event
that a problem relating to it is found, please inform the Central Secretariat at the address given below.
© ISO/IEC 1998
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.ch
Web www.iso.ch
Printed in Switzerland
ii © ISO/IEC 1998 – All rights reserved
© ISO/IEC ISO/IEC 14478-2:1998(E)
Contents
Foreword. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . vi
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . vii
1 Scope. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
2 Normative references. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
3 Definitions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
3.1 PREMO Part 1 definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
3.2 Additional definitions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
4 Symbols and abbreviations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
5 Conformance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
6 Foundation non-object types. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
7 Foundation object types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
7.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
7.2 PREMO objects and fundamental object behaviour . . . . . . . . . . . . . . . . . 5
7.2.1 Creation and destruction of objects. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
7.2.2 Inquiries on types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
7.3 Simple PREMO objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
7.3.1 Structures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
7.4 Callback objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
7.5 Enhanced PREMO Objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
7.5.1 Object properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
iii
7.6 Controller objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
7.7 Event handler objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
7.7.1 Basic Event Handler objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
7.7.2 Synchronization Points. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
7.8 Time objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
7.8.1 Clock object . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
7.8.2 System clock object . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
7.8.3 Timer object . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
7.9 Synchronization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
7.9.1 Event Synchronizable objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
7.9.2 Time synchronizable objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
7.9.3 Time slave objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
7.9.4 Time line objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
8 Enhanced property management and factories. . . . . . . . . . . . . . . . . . . . . . . 19
8.1 Enhanced Property management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
8.1.1 Motivation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
8.1.2 Capabilities and native property values: the PropertyInquiry type . . . . . . . . 20
8.1.3 Property constraint and selection: the PropertyConstraint type. . . . . . . . . . . 21
8.2 Creating PREMO objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
8.2.1 Generic Factory objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
9 Functional specification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
9.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
9.2 Common non–object data types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
9.3 Exceptions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
9.4 PREMOObject and fundamental object behaviour. . . . . . . . . . . . . . . . . 30
9.5 Simple PREMO object and structures. . . . . . . . . . . . . . . . . . . . . . . . . . . 31
9.5.1 SimplePREMOObject. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
9.5.2 Event structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
9.5.3 Constraint structure. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
9.5.4 Action Element . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
9.5.5 Synchronization Element . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
9.6 Callback objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
9.7 Enhanced PREMO object . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
9.8 Controller object . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
9.9 EventHandler objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
9.9.1 Basic event handler objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
9.9.2 SynchronizationPoint object. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
9.9.3 ANDSynchronizationPoint object . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
9.10 Timing objects. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
9.10.1 Clock object . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
9.10.2 SysClock object. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
9.10.3 Timer object . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
9.11 Synchronization objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
9.11.1 Synchronizable object. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
9.11.2 TimeSynchronizable object. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
9.11.3 TimeLine object . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
9.11.4 TimeSlave object. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
9.12 Enhanced Property management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
9.12.1 PropertyInquiry object . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
9.12.2 PropertyConstraint object . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
9.13 Creating PREMO objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
9.13.1 GenericFactory object . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
9.13.2 FactoryFinder object . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
10 Component specification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
A Overview of PREMO Foundation Object Types. . . . . . . . . . . . . . . . . . . . . . 66
iv
© ISO/IEC ISO/IEC 14478-2:1998(E)
B Extensibility for PREMO objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .70
C An example for event–based synchronization. . . . . . . . . . . . . . . . . . . . . . . . .71
v
Foreword
ISO (the International Organization for Standardization) and IEC (the International
Electrotechnical Commission) form the specialized system for worldwide standardi-
zation. 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.
International Standards are drafted in accordance with the rules given in the ISO/IEC
Directives, Part 3.
In the field of information technology, ISO and IEC have established a joint technical
committee, ISO/IEC JTC 1. Draft International Standards adopted by the joint technical
committee are circulated to national bodies for voting. Publication as an International
Standard requires approval by at least 75 % of the national bodies casting a vote.
Attention is drawn to the possibility that some of the elements of this part of
ISO/IEC 14478 may be the subject of patent rights. ISO and IEC shall not be held
responsible for identifying any or all such patent rights.
International Standard ISO/IEC 14478-2 was prepared by Joint Technical Committee
ISO/IEC JTC 1, Information technology, Subcommittee SC 24, Computer graphics and
image processing.
ISO/IEC 14478 consists of the following parts, under the general title Information
technology — Computer graphics and image processing — Presentation Environment
for Multimedia Objects (PREMO):
� Part 1: Fundamentals of PREMO
� Part 2: Foundation Component
� Part 3: Multimedia Systems Services
� Part 4: Modelling, rendering and interaction component
Annexes A and B form a normative part of this part of ISO/IEC 14478. Annex C is for
information only.
vi
© ISO/IEC ISO/IEC 14478-2:1998(E)
Introduction
This part of ISO/IEC 14478 defines those object types and non–object types which be-
long to the Foundation Component. Any conforming PREMO implementation shall
support these object types. The description of object types categories are given first
and then the foundation object types in each category are described.
vii
INTERNATIONAL STANDARD © ISO/IEC ISO/IEC 14478-2:1998(E)
Information technology — Computer graphics and image
processing — Presentation Environment for Multimedia Objects
(PREMO) —
Part 2: Foundation Component
1 Scope
This part of ISO/IEC 14478 lists an initial set of object types and non–object types useful for the construction of, presentation of,
and interaction with multimedia information. This part is dependent on the PREMO object model defined in clause 8 of ISO/IEC
14478-1. The foundation component does not depend on any other components.
2 Normative references
The following standards contain provisions which, through reference in this text, constitute provisions of this part of ISO/IEC
14478. At the time of publication, the editions indicated were valid. All standards are subject to revision, and parties to agree-
ments based on this part of ISO/IEC 14478 are encouraged to investigate the possibility of applying the most recent editions of
the standards indicated below. Members of IEC and ISO maintain registers of currently valid International Standards.
ISO/IEC 14478-1:1998, Information technology — Computer graphics and image processing — Presentation Environment for
Multimedia Objects (PREMO) — Part 1: Fundamentals of PREMO.
ISO/IEC 11172 (all parts), Information technology — Coding of moving pictures and associated audio for digital storage
media at up to about 1,5 Mbit/s.
3 Definitions
3.1 PREMO Part 1 definitions
This part of ISO/IEC 14478 makes use of all terms defined in ISO/IEC 14478-1 (Fundamentals of PREMO).
3.2 Additional definitions
For the purposes of this part of ISO/IEC 14478, the following definitions apply.
3.2.1 basic data type: Non-object data type which cannot be expressed via other data types. Examples are integers, float-
ing point numbers.
3.2.2 constructed data type: As opposed to basic data type; non-object data type which is constructed with the help of
permitted type constructors using basic data types.
3.2.3 time: A non–object data type which is appropriate for the representation of real time in the execution environment.
It is typically realized through either float numbers or large (64 bit) integers.
3.2.4 extended coordinates: An extension of real, integer, or time coordinates with the symbols –¥ and ,¥ and the nat-
ural comparison operators. It gives a succinct way of describing unlimited intervals on these coordinate systems.
3.2.5 key–value pair: A constructed data type, consisting of a key (described as a string) and a corresponding value.
3.2.6 foundation object type: Object types defined in the foundation component of PREMO.
3.2.7 structure: A category of object types in PREMO; these objects are characterized through attributes only.
3.2.7.1 structure tag: A synonym for an attribute for a structure.
3.2.8 property: Key with associated value or sequence of values, which can be attached to any PREMO object, and which
can be inquired, possibly created and deleted through operations defined on the object.
3.2.8.1 read–only property: A property whose value or values cannot be set by operations of the object.
3.2.9 fundamental object behaviour: Operations defined on the PREMOObject type; this type is the supertype of all
PREMO object types.
3.2.10 finite state machine: Implementation of an abstract finite state automaton.
3.2.11 constraint: A constructed data type, consisting of a key-value pair and an associated constraint operation; this latter
is used to compare the values, in case the keys are identical.
3.2.12 event: A constructed data type, serving as a basic building block for the PREMO Event Model.
3.2.12.1 event source: Object (instance) which creates events. This is a structure tag of an event.
3.2.12.2 event client: Object (instance) which consumes events.
3.2.12.3 event name: A means to denote and/or to refer to a specific event. This name is also referred to as event type.
This is a structure tag of an event.
3.2.12.4 event data: List of non-object types in the form of key–value pairs attached to an event. This is a structure tag
of an event.
3.2.13 event handler: An object which provides event processing services to other objects.
3.2.14 era: The base date for all PREMO systems to measure the amount of elapsed time. This value is set to 00:00am, 1st
January 1970, UTC.
3.2.15 reference point: A point in the internal coordinate system of a synchronizable objects, to which a synchronization
element is attached.
3.2.16 synchronization element: Synchronization information for a synchronizable object; it contains information on an-
other object and its operation which shall be invoked if synchronization is set up.
3.3.17 capability: Description of the property values an object type can take for a specific key.
3.3.18 native property value: Description of the property value an object instance can take for a specific key.
3.3.19 private properties: Properties of the object which are not defined as part of the functional specification of the object.
The following alphabetical list gives the sub-clause of each definition.
basic data type 3.2.1
capability 3.3.17
constraint 3.2.11
constructed data type 3.2.2
event 3.2.12
event client 3.2.12.2
event data 3.2.12.4
event handler 3.2.13
© ISO/IEC ISO/IEC 14478-2:1998(E)
event name 3.2.12.3
event source 3.2.12.1
event type 3.2.12.3
era 3.2.14
extended coordinates 3.2.4
finite state machine 3.2.10
foundation object type 3.2.6
fundamental object behaviour 3.2.9
key–value pair 3.2.5
native property value 3.3.18
private properties 3.3.19
property 3.2.8
read–only property 3.2.8.1
reference point 3.2.15
structure 3.2.7
structure tag 3.2.7.1
synchronization element 3.2.16
time 3.2.3
4 Symbols and abbreviations
AIFF: Audio Interchange File Format.
FSM: Finite State Machine.
IEC: International Electrotechnical Commission.
IS: International Standard.
ISO: International Organization for Standardization.
MPEG: Moving Picture Experts Group.
PREMO: Presentation Environments for Multimedia Objects.
2D: Two-dimensional.
3D: Three-dimensional.
5 Conformance
A conforming implementation of the PREMO Foundation Component shall comply with the general conformance rules defined
in clause 5 of ISO/IEC 14478-1 and the component specification in clause 10.
6 Foundation non-object types
The foundation non–object types in PREMO are defined in two categories: basic data types, and data types directly defined from
these basic data types in terms of the notations described in clause A.2 of ISO/IEC 14478-1.
The basic data types are (with their type names):
a) N: non-negative integer.
b) Z: integer.
c) R: real number.
d) ObjectType: a data type uniquely identifying an object type.
e) EventId: a data type uniquely identifying an event registration for a PREMO event handler.
f) Time: a data type to measure progression of real world time. This type is either a real number or a (possibly large) inte-
ger. The choice among these is implementation dependent.
g) As described in 8.5 of ISO/IEC 14478-1, for each object of type T an object reference type, which is a non–object type,
referring to object instances of type T, automatically exists in PREMO. As a notational convention, RefT denotes the non–
object type of object reference referring to object instances of type T.
The environment shall provide comparison facilities for each basic data type which unambiguously decide whether two data val-
ues are identical or not. In the case of object references the environment shall also include a facility to test whether two references
refer to the same object instance or not, or whether the value of the object reference is NULLObject. How these facilities are re-
alized depends on the programming language and the execution environment in which PREMO is implemented.
Coordinate spaces can be “extended” to include positive and negative “infinity”. Although the underlying implementation may
not have a direct representation of these types, the obvious extension of the notion of “greater than”, “smaller than”, etc., on these
types allows the behaviour of objects to be defined more succinctly. The following extended coordinate space definitions are
used:
h) Extended real numbers:
R == R È{–¥,}¥
¥
i) Extended integers:
Z == Z È{–¥,}¥
¥
j) Extended time:
Time == Time È{–¥,}¥
¥
The foundation object types, described in this part, make also use of a number of (constructed) non–object types, defined formally
in 9.2 (page 27). Some of these non–object types play a key role in the behavioural description of several object types; they are
therefore also listed here, to make the semantic description in clause 7 easier to follow.
— Boolean:
Boolean ::= TRUE ½ FALSE
— Character String:
String ::= seq Char
— Constraint specification for key–value pairs (used, for example, by property management, event handlers, and aggregate
object types):
© ISO/IEC ISO/IEC 14478-2:1998(E)
ConstraintOp ::= Equal ½ NotEqual
½GreaterThan½ GreaterThanOrEqual½½LessThan LessThanOrEqual
½Prefix½ Suffix½½NotPrefix NotSuffix
½Includes ½ Excludes
Values in an operation request are constrained to values which satisfy these type constraints and the constructions defined in
clause A.2 of ISO/IEC 14478-1 (see also 8.6 of ISO/IEC 14478-1). No particular representation for these values is mandated by
the PREMO functional specification, although bindings of PREMO to programming languages or to distributed programming
paradigms may specify such formats.
7 Foundation object types
7.1 Introduction
Foundation objects types are those which support a fundamental set of services suitable for use by a wide variety of higher level
components. PREMO conformance rules require that, whenever a PREMO implementation includes these objects, they be in-
cluded in the manner specified in this clause. This is the basis for interoperability. The following criteria are used to identify foun-
dation objects:
a) they are used by a majority of higher level components;
b) together they provide an adequate minimal functional set;
c) they are needed to support output on widely available presentation resources;
d) algorithms exist for decomposing more complex functionality into the foundation object types.
In this clause, foundation object types are identified. By means of subtyping the application developer or component supplier
may create objects and object types for their own specific needs. Clause 9 of this part gives the detailed definitions of each of
these object types; clause A gives an pictorial overview of all object types defined in this clause.
7.2 PREMO objects and fundamental object behaviour
All PREMO objects are assumed to be subtyped from a type called PREMOObject. PREMOObject is an abstract type, i.e., it is
not instantiable.
Operations on PREMOObject type fall into two categories described below.
7.2.1 Creation and destruction of objects
These operations are used by the object and object reference life cycle facilities when object instances are created and destroyed
(see 8.11 of ISO/IEC 14478-1 for a detailed description of these facilities). The initialize, initializeOnCopy, and destruct opera-
tions are defined to be protected, i.e., no other PREMO object can re–initialize a PREMO object or directly call the destruct op-
eration, only through the facilities provided by the environment.
7.2.2 Inquiries on types
These operations return information on the object type, the sequence of supertypes, or the complete type graph of the object. Us-
ing the information returned by these operations, complex negotiations are possible to optimize the behaviour of various other
PREMO objects.
7.3 Simple PREMO objects
SimplePREMOObject is an abstract subtype of PREMOObject. SimplePREMOObject does not extend the behaviour of PRE-
MOObject, but serves as a common supertype for a family of PREMO objects, called structures. Using such a supertype allows
operation specifications to impose type constraints on their arguments.
7.3.1 Structures
The term “structure” does not denote a specific object type in PREMO but, instead, a category of types. These object types are
characterized by:
a) they are the subtypes of SimplePREMOObject but are not subtypes of EnhancedPREMOObject;
b) they are not abstract types, although they may be generic types;
c) their behaviour in PREMO is expressed in terms of attributes rather than explicit operations (apart from the operations
inherited from the supertype PREMOObject).
The attributes of a structure are also referred to as “structure tags”.
NOTE — Implementations, or further components, may define subtypes of structures by adding operations to the type specification. Item c
above does not preclude this. However, as a use of terminology, such types are not labelled as “structures” any more.
Structures can be used as tools to encapsulate various non–object data into the object hierarchy. As an example, the following
object type is used to describe constraints on key–value pairs:
Constraint
SimplePREMOObject
constraintOp: ConstraintOp
kv: Key ´ Value
Constraint
(This structure, formally defined in 9.5, plays an important role in the behavioural description of various objects in PREMO.)
NOTE — To increase the efficiency of the implementations, some programming languages may choose to implement structures as special
data types and not as objects.
One of the most important structures used in PREMO is the event structure. Events structures consist of the following structure
tags (see 9.5 for the precise specifications): an event name that provides a means to denote or refer to the event, also referred to
as event type, an event data which is a sequence of key–value pairs, and the event source, which is the reference to the object
instance which has created this event.
7.4 Callback objects
Very often object instances have to be notified by other objects on some status change, event occurrences, etc. This is done by
‘registering interest’ in some events. PREMO defines an abstract type, called Callback, to facilitate such mechanisms.
The Callback object type defines one single asynchronous operation, called callback. The signature of this operation consists of
one input argument, which is a reference to an Event structure (see 9.5.2 for a detailed specification of this structure). Various
PREMO objects, which may have to be notified under various circumstances, are defined to be subtypes of Callback, defining a
type–specific behaviour to the callback operation.
NOTE — A typical example for the usage of the callback mechanism is the PREMO Event Model, described in detail in 7.7.1.
© ISO/IEC ISO/IEC 14478-2:1998(E)
Whereas, in simple cases, the semantics of the callback operation may be defined to affect the state of the object directly, it is
very often the case that this operation acts only as an entry point to call other operations on the object. To facilitate this second
case, PREMO also defines a subtype of Callback, called CallbackByName. The (inherited) asynchronous callback operation of
CallbackByName has the following behaviour: the eventName structure tag of the Event structure (appearing as the input argu-
ment of callback) is interpreted to be the name of a local operation which is then internally invoked by the callback operation.
By default, all other structure tags of the Event structure are disregarded by the callback operation; subtypes of CallbackByName
may add an additional behaviour to the operation which also takes these tags into consideration.
7.5 Enhanced PREMO Objects
EnhancedPREMOObject is an abstract type, i.e., is not instantiable. This type describes a set of behaviour, referred to as the en-
hanced object behaviour. The operations on EnhancedPREMOObject are related to object properties.
Enhanced PREMOObject represents the common, abstract supertype for PREMO objects with a more complex behaviour than,
for example, structures. An important restriction in PREMO, which also reflects this characterization, is that only subtypes of
EnhancedPREMOObject can appear in the provides service sub–schemas of profile specification (see clause 9 of ISO/IEC
14478-1).
7.5.1 Object properties
Properties are used to store values with an object that may be dynamically defined and are outside of the type system. Properties
1)
are pairs of keys and a sequence of values which are conceptually stored within a PREMO object. Operations are introduced to
define, undefine, and inquire properties on PREMO object instances. Because, in general, the same key refers to a sequence of
possible values, operations are also defined to add and to delete values from a sequence associated with a key. Properties can be
used to implement various naming mechanisms, store information on the location of the object in a network, create annotations
on object instances, etc.
Properties may be defined as read only. This means that they cannot be defined through an operation on the object, nor can they,
or their associated values, be changed or deleted. Read only properties are typically set by the object when being initialized, and
are used to describe the various capabilities of the object.
Properties of an object can also be matched against another list of key–value pairs using the matchProperties operation. This op-
eration accepts a sequence of constraints, each defining a sequence of possible values for a specific property key, and returns the
sequence of satisfied and unsatisfied constraints. Satisfaction is based on the boolean operation defined by the non–object data
type ConstraintOp, see 9.2 (page 27), where the left operand of the operation is the value stored in the object, and the right op-
erand of the operation is the value appearing in the argument of matchProperties (if the operation does not make sense, the result
of the comparison is FALSE, i.e., it is the client’s responsibility to ensure that the arguments are comparable). This mechanism
may be used as part of complex negotiations.
NOTE — An example of using property matching is identifying the possible file formats of an audio service. The object providing the service
may define a (read–only) sequence of values for the key “AudioFormatK”, e.g., <“AIFF”, “IRCAM”>, describing the file formats it can use.
The matchProperties operation may be invoked with a pair consisting of a key and a value, e.g.,
[“AudioFormatK”, “AIFF”]
using the comparison operator “Equal”. The result will be:
satisfied: [“AudioFormatK”, <“AIFF”>]
unsatisfied: [“AudioFormatK”, <“IRCAM”>]
Another call, using:
[“AudioFormatK”, “IRCAM”]
1)
A sequence may have only one element
will result in:
satisfied: [“AudioFormatK”, <>]
unsatisfied: [“AudioFormatK”, <“AIFF”, “IRCAM”>]
Based on this information the client may choose the AIFF file format which can be managed both by itself and the audio service. By using
more than one key in the invocation of the matchProperties operation (e.g., also include sampling size), powerful negotiations may be
implemented.
As a notational convenience if, in the case of a type hierarchy, it is necessary to stress that a certain property key is defined on a
specific type, the notation Type::key will be used.
NOTE — For example, the notation PREMOObject::InternetLocationK may refer to a property key defined on the type PREMOObject; on the
other hand, AudioDevice::InputEncoding refers to a property which is defined on the type AudioDevice, but not (necessarily) on its
supertypes.
By default, if a property value is defined for a key which already exists for the object instance, the old value is overwritten. How-
ever, the client has the possibility to add the reference of a Callback object, with a corresponding event name, to a property key.
The callback is activated whenever a new value is defined for the key; the event structure instance sent to the Callback object
contains the key–value pair corresponding to the new setting.
The detailed functional specification of PREMO objects may contain property specifications, too. This means that the corre-
sponding property keys are automatically defined for these objects at object creation time, together with the values the functional
specification may also contain. These keys are therefore always available for an object instance. This property initialization
mechanism is conceptually part of the object’s behaviour, and is inherited by all its subtypes.
7.6 Controller objects
A PREMO object may want to communicate with other objects by operation requests. Some of these request may be related to
events generated by event sources such as input devices, synchronization requests, etc. An event may require actions by several
different objects. The Controller object type provides facilities to coordinate this cooperation among the different objects.
An instance of the Controller object type is a programmable finite state machine (FSM), i.e., an abstract automaton with a finite
number of internal states and a set of state transition rules. Transitions among states are produced when other objects invoke the
handleEvent operation, which receives a reference to an Event structure as input argument. Subtypes of Controller define the
exact set of states and the corresponding state transition rules; implementations may also choose to defer the definition of states
and transition rules for a specific subtype of Controller to the final application and offer means to the end–user to program these
states and rules. (The set of all possible states for a specific Controller instance is defined as a retrieve only attribute of the object,
i.e., a client can always find out what states the object may take.) Typically, a controller object registers itself with an event han-
dler or another controller. This event handler can cause a transition of states within the controller object. Actions taken by the
FSM may include invoking operations of other objects, including other controller objects. Thus, a hierarchy of controller objects
can be built.
NOTE — Controller objects can be used for different purposes. An example for their use is to implement complex interactions such as
dragging graphical objects. In this interaction, a mouse-down event puts the interaction in a different mode that causes an object to be dragged
on the screen using the mouse, until a mouse-up event is received. This can be viewed as an example of an FSM going through different states,
where the user events trigger the transitions.
State transitions in controllers may be subject to constraints and are monitorable. Constraining state transitions mean dynamic
control over whether a state transition should really occur or not, and this decision may also depend on the data associated to the
event appearing as the input argument of handleEvent. Monitoring state transitions means that callbacks and local operations can
be associated to the various steps of a state transition, i.e., the targets of the callback operations can be notified if a state transition
occurs.
© ISO/IEC ISO/IEC 14478-2:1998(E)
2. call local operation
1. check validity of State
‘onLeave’
to State transition
State
3. perform callback for
‘Leave’
4. perform callback for
(State ,State )
handleEvent
1 2
5. call local operation
‘onEnter’
6. perform callback for
‘Enter’
State
Figure 1 — Controller objects
The detailed specification of a controller is as follows (see also Figure 1):
— Each state in a Controller is identified by a symbolic name, i.e., a string.
— A special structure type, called ActionElement, is defined (see also 9.5.4), containing an event name and a reference to a
callback object. Operations are defined on the Controller object type to add or remove such ActionElement structures to each
state. Each state may have two such associated structures, labelled respectively ‘Enter’ and ‘Leave’. Also, and independently
of the structures associated to the states themselves, such structures may be associated to pairs of states.
— The following protected operations are defined on Controller: checkTransition, handleUnknownEvent, onLeave, and
onEnter. Although a default behaviour is defined for each of these operations, the intention is that subtypes of Controller
redefine these operations to suit the subtype’s behaviour. A retrieve only attribute, denoting the current state, is also defined
for Controller.
— With these definitions, the basic steps for a state transition of a Controller are as follows:
1) A state transition is requested by a client through the invocation of the operation handleEvent. The event name is
interpreted to be the state name to which the Controller object should transit. For the sake of this discussion, State is the
name of the current state of the object, and State is the name of the requested state.
2) The controller object invokes the local, protected operation checkTransition, forwarding the argument of han-
dleEvent. This operation returns a boolean value indicating whether the transition is allowed.
3) If the transition is not allowed, the local, protected operation handleUnknownEvent is invoked, forwarding the argu-
ment of handleEvent, and handleEvent finishes.
4) If the transition is allowed, the following steps are executed:
i) The local, protected operation onLeave is invoked. This operation receives as arguments the event structure
appearing as the argument of handleEvent, as well as (the strings) State and State . The operation returns data suita-
1 2
ble for an event data tag in an event structure.
ii) If there is no ActionElement structure associated to State labelled as ‘Leave’, this step is ignored. Otherwise, an
event instance is created, using the event name in the ActionElement structure associated to State labelled as ‘Leave’,
and the event data returned by onLeave. A callback is executed with the newly created event instance as argument.
iii) The value of the attribute denoting the current state is set to State .
iv) If an ActionElement is associated to the tuple State ´ State , a new event instance is created using the event name
1 2
in the ActionElement and the tuple State ´ State as event data with the key “Transition”. The callback operation on
1 2
the Callback object referenced by the ActionElement is then invoked using this new event instance.
v) The local, protected operation onEnter is invoked. This operation receives as arguments the event structure
appearing as the argument of handleEvent, as well as (the strings) State and State . The operation returns data suita-
1 2
ble as an event data tag in an event structure.
vi) If there is no ActionElement structure associated to State labelled as ‘Enter’, this step is ignored. Otherwise, an
event instance is created, using the event name in the ActionElement structure associated to State labelled as ‘Enter’,
and the event data returned by onEnter. A callback is executed with the newly created event instance as argument.
NOTE — The onEnter and onLeave operation may be used, for example, to control the prompt and/or the echo of an elementary step in an
interaction.
Controller objects are themselves defined to be subtypes of Callback, where the callback operation, inherited from Callback, is
identified with the operation handleEvent. Consequently, controller objects may also be chained to form more complex interac-
tion patterns.
7.7 Event handler objects
7.7.1 Basic Event Handler objects
Events form a special category of PREMO structure types and are the basic building block for the PREMO Event Model. This
model is based on a small number of basic concepts: events, event registration, and event handling. An event can model any action
that occurs at a definite time. Events are created by event sources, and are consumed by event clients, which are both object in-
stances. A basic characteristic of an event is its name, which is one of the features that an event client uses to identify the events
in which it is interested.
When using normal operation requests among objects the caller specifies the recipient of each request. When using event handler
objects, as shown in Figure 2, events are not addressed to specific recipients. It is the recipient that determines which event types
it wishes to receive. Event recipients are operations defined on the recipient object.
EventHandler objects provide the necessary event management services to other objects. This object type provides the following
operations (see also Figure 2):
a) register interest in events (the register operation),
b) unregister interest in events (the unregister operation), and
c) dispatch an event (the asynchronous dispatchEvent operation).
The operation to dispatch an event is usually invoked on the EventHandler object by the event source. The EventHandler will
then forward the event to all recipients which have expressed their interest in this specific event.
The choice of the recipients for the event to be handled is determined by the way the recipients have registered their interest in
specific event types. This choice is based primarily on the name of the event (i.e., its type), but may also be associated with a
constraint list, i.e., a sequence of key–value pairs with constraint operations. This constraint list gives a finer control on whether
the event client is notified of the arrival of an event or not. The semantics of the constraint matching is as follows: the key–value
pairs of the constraint list are compared to the event data of the incoming event instance. If there is a match in the keys, the com-
parison operation of the constraint is applied to compare the values. Comparison is based on the boolean operation defined within
the structure ConstraintOp, (see 9.5), where the left operand of the operation is the value stored in the event handler, and the right
operand of the operation is the value appearing in the incoming event instance (if the operation is undefined on these operands,
e.g., the types are different, the result of the comparison is FALSE). During registration, the prospective event client can control
whether the result of the full constraint matching is the logical conjunction or the disjunction of the individual constraint matches.
If this result is TRUE, the event client is notified; if it is FALSE, it is not.
© ISO/IEC ISO/IEC 14478-2:1998(E)
EventClient1
callback
…
EventHandler
dispatchEvent
dispatchEvent
register
…
EventSource
EventClient2
callback
…
register
Figure 2 — PREMO event model
Objects, which can be registered within an event handler, shall be subtypes of Callback (see 7.4). The event handler calls the
operation callback on these objects to achieve dispatching.
The registration of an event recipient within an event handler is identified through a non–object data type EventId; a value of this
type is returned when an event is registered. This value shall be used when, subsequently, the object is no longer interested in this
event, and the
...
Questions, Comments and Discussion
Ask us and Technical Secretary will try to provide an answer. You can facilitate discussion about the standard in here.
Loading comments...