Download

Hinweis: Dieser Titel ist nur in englischer Sprache erhältlich.
Note: This title is availabe only in the English language.
Remarque : Ce rapport n’est disponible qu’en anglais.
IfraTrack 3.0
Ifra Special Report 6.21.3

02
Introduction
Ifra Special Report 6.21.3
© 2002 Ifra, Darmstadt
Imprint
Ifra Special Reports, research reports, technical study reports and documents for the standardisation of newspaper
production techniques. Published by: Ifra, Washingtonplatz, 64287 Darmstadt, Germany; www.ifra.com; Tel. +49.6151.
733-6; Fax +49.6151.733-800. Chief Executive Officer: Reiner Mittelbach. Director of Research and Consulting:
Manfred Werfel. Research Manager: Uwe Junglas. Republishing – also of excerpts – only with express permission of Ifra
and acknowledgement of origin. Price: Ifra Special Reports are sold at the price of 130 EUR* per copy. For Ifra members,
the price is covered by the membership fee that entitles them to an allotted number of copies. Ifra members may order additional
copies at 13 EUR* per copy.
* plus 7% VAT in Germany and for companies and persons in the European Union that do not have a VAT number.

© 2002 Ifra, Darmstadt
Ifra Special Report 6.21.3
Table of contents
03
Table of contents
Introduction ............................................................................................................................................................ 04
Acknowledgements ................................................................................................................................................. 05
1 Background .......................................................................................................................................................... 06
1.1 Nature and structure of the newspaper production process ................................................................................... 06
1.2 Need for production management in newspapers .................................................................................................. 06
1.3 Need to exchange production information between systems ................................................................................. 06
2 Scope and purpose of the IfraTrack specification .......................................................................................... 07
2.1 Primary scope of IfraTrack ....................................................................................................................................... 07
2.2 Different levels of detail .......................................................................................................................................... 07
2.3 Creating a method for the interchange of status and management information ..................................................... 08
3 Introducing a production management system ............................................................................................. 09
3.1 The interaction between the process and the business .......................................................................................... 09
4 The IfraTrack object concept .............................................................................................................................. 10
4.1 Background and definitions ................................................................................................................................... 10
4.2 Trackable objects .................................................................................................................................................... 10
4.3 Object structure ...................................................................................................................................................... 10
4.4 Object classes ......................................................................................................................................................... 10
4.5 Attributes and links ................................................................................................................................................. 10
5 States of objects .................................................................................................................................................. 12
5.1 Background ............................................................................................................................................................. 12
5.2 Workflow states ...................................................................................................................................................... 12
5.3 Dual state concept .................................................................................................................................................. 12
5.4 Deadlines ................................................................................................................................................................ 12
5.5 Resource ................................................................................................................................................................. 12
6Message format ................................................................................................................................................... 13
6.1 Background ............................................................................................................................................................. 13
6.2 The Ifra Message Format ......................................................................................................................................... 13
7 Message exchange mechanism ........................................................................................................................ 14
7.1 Background ............................................................................................................................................................. 14
7.2 Example 1 – Central database approach .................................................................................................................. 14
7.3 Example 2 – File exchange approach ...................................................................................................................... 15
7.4 Example 3 – TCP/IP socket approach ...................................................................................................................... 15
7.5 Time synchronisation between systems ................................................................................................................. 15
8 Using and maintaining the specification ........................................................................................................ 16
8.1 Exchanging information between production tracking systems and building global tracking systems ................... 16
8.2 Subscribing to the specification and use of the IfraTrack logotype ......................................................................... 16
8.3 IfraTrack on the Web ............................................................................................................................................... 16
8.4 Registering new object classes and attributes ........................................................................................................ 16
8.5 Ifra’s role in maintaining the specification .............................................................................................................. 16
9 Future extensions to the specification ............................................................................................................. 17
9.1 Possible extension into scheduling and control ...................................................................................................... 17
9.2 A more generalised model ...................................................................................................................................... 17
9.3 Further integration with JDF .................................................................................................................................... 17
9.4 Version control ........................................................................................................................................................ 17
9.5 An extended distribution model .............................................................................................................................. 17
9.6 IfraTrack queries ..................................................................................................................................................... 18
9.7 Cost estimation ....................................................................................................................................................... 18
Appendix A – IfraTrack object classes ................................................................................................................................ 19
Appendix B – The Ifra Message Format .............................................................................................................................. 23
Appendix C – The standard IMF schema ............................................................................................................................. 29
Appendix D – Extending the standard IMF schema ............................................................................................................ 35
Appendix E – Examples ...................................................................................................................................................... 36
Appendix F – CIP4 and JDF ................................................................................................................................................. 47

04
Table of contents
Ifra Special Report 6.21.3
© 2002 Ifra, Darmstadt
IfraTrack 3.0
an XML-based specification for the interchange of status and management information between local and
global production management systems in newspaper production
The modernisation of newspaper companies with computerised pre-press departments and highly automated printing
presses and mailrooms is today one of the biggest revolutions in the newspaper industry. However, total production management
using computer-based tracking and active process control is still almost absent from newspaper production. In
the future, pre-press, press, mailroom and distribution control systems will be linked to form an integrated newspaper production
management system focusing on customer-to-customer satisfaction.
In 1994, a working group was formed to devise a recommendation for the interconnection of local production tracking
systems from different manufacturers. These efforts resulted in the first version of IfraTrack. In 1997, a second working
group was formed to continue the process.
In 1999 a third working group was formed mainly to change the proprietary message format into a new XML-based format.
This report contains the resulting IfraTrack 3.0 specification. The explanatory part of the text is based on the “Ifra
Special Report 6.21.2”, which describes the previous version of IfraTrack.
In addition to this report, an “Executive summary” is available as “Ifra Special Report 6.21.1”. For background information,
scope and purpose of the IfraTrack specification we refer to the executive summary.
We hope that IfraTrack will find a wide acceptance in the industry.
Fredrik Fällström
MWM Media Workflow Management AB
Februar 2002
Introduction
The Internet changes everything – not only the way people interact and communicate, also the way systems interact and
communicate. With millions of people using the Internet there is no room anymore for a specialised niche market like
newspaper publishing. The Internet, the world-wide web and the W3C-Organisation as the administrator for all webstandards
determine the direction of software development and communication. Waiting for the official release of XML
Schema from W3C has delayed this report for some time. Now it is there and in the meantime the XML specification has
had time to mature.
If you read through the text of the report you might find that there have not been many changes – but this time the
major changes are in the appendices – the XML Schema definitions.
Now, where the road is paved with XML, it is time to drive and develop applications.
Harald Löffler
Ifra Consulting Manager
Dr. Stig Nordqvist
Tidningsutgivarna

© 2002 Ifra, Darmstadt
Ifra Special Report 6.21.3
Acknowledgements
05
Acknowledgements
On the initiative of the Ifra Pre-Press Committee, a Working Group was formed in 1994 to work on production tracking.
The result of the work was IfraTrack 1.0 and 1.1. 1997 the work continued and resulted in version 2.0. This report was
produced as a result of the work in 1999 and 2000 by the IfraTrack Working Group 3.0.
The working group consisted of the following members:
Christian Anschütz
Richard Brägger
Jean-Noel Clerc
Dave Collette
Stefan Daun
Matthias Dürr
Henrik Edström
Per Eriksson
Rüdiger Ewert
Fredrik Fällström
Stig Forsberg
Richard Hächler
Björn Hedin
Harald Löffler
Dr. Stig Nordqvist
Richard Patterson
Dr. Rainer Prosi
Martin Ruhle
Dag Sundman
Frank Theede
Hannu Tiihonen
Brian Travis
Björn Zitting
Heidelberger Druckmaschinen AG
Ringier AG
Insert Graphiques
Associated MediaBase Ltd
FhG-IGD Fraunhofer-Institut für Graphische Datenverarbeitung
Ferag AG Förder- und Verarbeitungssysteme
MWM Media Workflow Management AB
DENEX Systems Technology AB
EAE Ewert Ahrensburg Electronic GmbH
MWM Media Workflow Management AB, Technology Supervisor
Ifra Nordic
ABB Industrie AG Geschäftsgebiet Druckereien
Royal Institute of Technology Division of Media Tech. & Graphic
Ifra, Secretary
Tidningsutgivarna (TU), Chairman
Associated Media Base Ltd
Heidelberger Druckmaschinen AG
PPI – Pape + Partner Media GmbH
CATS Comp. & Audio-Technical Systems AB
PPI – Pape + Partner Media GmbH
Honeywell OY
Architag International Corp., XML Expert
IKEA Catalogue Services AB
The working group thanks Günther W. Böttcher, Prof. Nils Enlund and Boris Fuchs who initiated the process.

06
1 Background
Ifra Special Report 6.21.3
© 2002 Ifra, Darmstadt
1 Background
1.1 Nature and structure of the newspaper
production process
One of the important aspects in newspaper production
is the fact that the product is not completely defined when
production starts. Outside events can change the contents
and structure of the product radically at a very late point
in time: every day the product is different. Still, production
schedules have to be kept and a complete newspaper has
to be delivered to the reader on time.
The newspaper production process consists of two distinct
and very different production processes:
> The aim of the first process is to make an original. It
is the creative process of putting together the newspaper
pages with their mixed content of editorial and
advertising matter. Each newspaper has two main prepress
departments doing a parallel production of originals.
The ad department sells page space and collects
as well as produces advertisements corresponding to
that space. The editorial department collects information
and through a complex process of selection, creation
and editing, fills the pages in a structured way.
> This is followed by the rapid mass production and distribution
of copies of this original. The manufacturing
of copies is a linear production process. The main production
steps are platemaking, printing, insertion of
pre-prints, addressing of mailed copies, stacking,
bundling, transportation and delivery. This is a traditional
manufacturing process and it can be managed,
controlled and optimised through the use of resource
management methods and systems.
1.2 Need for production management in newspapers
When making a newspaper, one problem is to make
sure that the production process is running according to
the schedules and to the budget. Today, production in most
newspapers is managed by information residing in the
minds of a few persons, responsible for getting the newspaper
out on deadline.
But, especially in the pre-press area, the technology is
making this kind of production management more and
more problematic. The emergence of low cost, high performance
text, image and page processing software for
standard platform computers has made the digital production
of newspaper pages more accessible. Within a short
time span, all newspaper pre-press production will be handled
digitally and this will lead to a new structure in the
pre-press area. For example, the traditional typesetting and
repro departments will disappear in their present form.
Organisational structures will adapt to technical and functional
realities. The flow of material in digital form will
have to be managed by electronic means, since no physical
material exists that could be tracked mechanically or
manually.
The tracking of events and objects in the newspaper
production process is today, when present at all, handled
by function-based, local tracking systems. Separate solutions
from different manufacturers exist for mailroom
management, press control, page output and printing plate
tracking. In the pre-press area, production tracking, outside
ad tracking, have only been addressed recently by
system manufacturers.
The idea of automatically tracking newspaper production
is relatively new in the newspaper industry. In other
branches of industry there are very well developed production
management systems aiming at optimising the
production. Since business has been running well in the
newspaper industry, there was no need for production
tracking. The current economic situation also increases the
interest in efficient monitoring and management of the
entire newspaper production process, just like any other
industrial production. There is a need for a better production
control.
1.3 Need to exchange production information between
systems
To be able to follow the progress of a page from page
make-up through imaging and platemaking to press
mounting, there is a need to exchange status and management
information between local systems.
In order to make this possible, some mechanisms have
to be developed to enable for example the press management
system to communicate with the mailroom system.
More important, this mechanism will also enable the creation
of an company-wide layer (Global Production Management
System, GPMS) that can be used by the management
and employees to follow what is planned and what is
happening in the whole process.
There is a definite need in newspapers for extending
production tracking and management to cover the entire
manufacturing process, from news gathering and ad marketing
to the delivery of printed copies. A global production
management system has to serve the needs of business
management and should provide the tools for extracting
high level planning and decision information from the
different local systems. It should also serve as a distributor
of information between the different areas of responsibility
within the newspaper production process.
Pre-press
Management
System
Press
Management
System
Mailroom
Management
System
Global Production Management System
Distribution
Management
System
Figure 1: Exchanging information between local systems makes global production
management possible.

© 2002 Ifra, Darmstadt
Ifra Special Report 6.21.3
2 Scope and purpose of the IfraTrack specification
07
2 Scope and purpose of the IfraTrack specification
2.1 Primary scope of IfraTrack
Several production management systems are available
today from different manufacturers and many new solutions
are under development. Each of these systems takes
its own approach to solving a locally defined tracking
problem. There is no reason for an attempt to standardise
these approaches – this could hamper innovation in a rapidly
developing sector. Instead, ways and methods to be
used by local production tracking systems to communicate
with other systems should be defined in a structured manner.
The primary objective of the IfraTrack specification is
to define a way of exchanging status and management information
between local and global systems. The proposed
mechanism will make possible the creation of a global
newspaper production tracking and planning system that
can collect the information from the various local systems.
2.2 Different levels of detail
Any proposed standard method should be kept as simple
as possible. The format has to be flexible enough to
handle all the necessary status and management information
on various levels of details. The newspaper production
process can be planned, observed and tracked at different
levels of detail. On a very high level, we can observe the
process as consisting of four main functions: pre-press,
press, mailroom and distribution. Looking closer at the
pre-press department, we can distinguish between: editorial,
advertising, composing room, repro and platemaking.
And going even further, we can for example observe the
different steps necessary to produce advertisements. These
views represent different levels of detail.
The level of detail is important when it comes to production
tracking and management. Local production management
systems work internally at a certain level of detail
and they would communicate with other systems on another
level. For example, an ad system is concerned with
bookings, texts, images, layouts and complete ads. A plate
management system is concerned with pages, paste-ups,
films, printing plates, register punches, benders and plate
conveyors. Another system might only be concerned with
plates, presses, copies, bundles and vans. Still, all these
systems need to exchange information. Any recommendation
for the exchange of information between systems
should be able to work at these different levels of detail.
This means that the recommendation should be built as an
extensible architecture.
On the other hand, global management cannot be
made on a too detailed level. The consequence would be
too heavy traffic on the network with thousands of messages
being sent when events occur at every level of the
production process. It is also important to build a general
but strict method that can be used in many different areas,
for example in the commercial printing industry.

08
2 Scope and purpose of the IfraTrack specification
Ifra Special Report 6.21.3
© 2002 Ifra, Darmstadt
Ads
Pre-press
Global view of the newspaper production process
Newsprint
Bundles
Plates Copies Bundles
Press
Mailroom
Distribution
Editorial
matter
Inks
Copies
Closer look at a simplified traditional pre-press process
Ads
Pre-press
Ad
processing
Ads
Photocomposition
Composed
items
Page
make-up
Images
Stories
Processed
images
Films
Platemaking
Plates
Editorial
processing
Images
Image
processing
Editorial matter
Figure 2: Different levels of detail.
2.3 Creating a method for the interchange of status
and management information
Implementing a global management system would be
relatively easy if all the tools used would be part of the
same single vendor system. Production control could then
be superimposed on a common database system. This is
not the case in the newspaper industry, where different
systems from different manufacturers will have to communicate
between each other. To be able to achieve it, a common
accepted approach has to be taken.
The enforcement of standards in a rapidly developing
environment is almost impossible. The Ifra initiative which
started in 1994 does not aim at creating a restrictive standard.
Instead, a structured and open method for exchanging
tracking information has been developed. During the
development work, the aim has always been to make the
final implementation as simple as possible.
A standard message format, version 3.0, has been defined
by the IfraTrack Working Group 3. Its members
range from newspapers to systems suppliers for the prepress,
press and mailroom departments. The addition of
Ifra-recommended IfraTrack messages to existing and
planned systems will be a simple task for the systems
manufacturers. The specification is independent of the system
vendor and the platform used. For the newspapers, the
fact that a local management system adheres to IfraTrack
message passing specification will be a guarantee that it
will be able to communicate with other systems.

© 2002 Ifra, Darmstadt
Ifra Special Report 6.21.3
3 Introducing a production management system
09
3 Introducing a production management system
3.1 The interaction between the process
and the business
The production process of a newspaper and a global
production management system can be interconnected using
IfraTrack as discussed above. The two, in combination
with the economic control mechanisms of the newspaper
company constitute a powerful tool.
The economics of the newspaper are controlled by the
demands for profit, and/or based on advertising goals.
These advertising goals also demand a healthy economical
situation for the newspaper company. The economic system
could be connected to the production process through
the use of a global production management system that
facilitates real time feedback. The production process needs
resources, i.e. persons, material and machines, to be able to
manufacture and deliver products. The gpms can, from a
company holistic point of view, be seen as a vital part of
the newspaper, where both economic and production aspects
play important roles.
The use of a gpms that interacts with other systems
through an open and standardised exchange format as
IfraTrack, promises the use of more flexible product structures
and, at the same time, better utilisation of available
processes and resources. At the bottom line, this will save
time and money.

10
4 The IfraTrack object concept
Ifra Special Report 6.21.3
© 2002 Ifra, Darmstadt
4 The IfraTrack object concept
4.1 Background and definitions
Production tracking is concerned with objects and their
states. The objects are divided into different object classes.
The status of an object is modified through processes. The
changing of the status of an object is called an event. Production
tracking consists on the registration of events. By
associating the events with objects and their status, a tracking
system can follow the progress of the production run.
The IfraTrack specification is defining a general tracking
message exchange method. A “sender” is a system that
generates a tracking message and a “receiver” is any system
that can register and use this tracking message.
The specification is based on three main points:
> Semantics: the scope and content of the tracking data
to be communicated is defined.
> Syntax: the method of describing and encoding the
tracking messages is specified. The systems that send
and receive messages have to be uniquely named. The
objects concerned by the messages should also be
identified. All this information has to be encoded,
preferably in a human readable form.
> Message exchange mechanism: the method to
exchange the tracking messages is also defined.
4.2 Trackable objects
The Production Tracking Working Group has tried to
find a basic model for newspaper production. This model
gives some examples of trackable objects which go
through the different production steps.
4.3 Object structure
Objects used in newspaper production have a certain
structure. For example:
> a page consists of stories and ads, which can
themselves consist of texts, images and lineart.
> a newspaper issue on a certain day consist of
different editions.
This structure means that some objects will be linked
to other objects. For example, the elements composing a
page will be linked to that particular page.
Trackable objects are not necessarily physical objects,
but can also be process objects, like for example, a printing
job in the press department.
4.4 Object classes
In its attempt to find a model for newspaper production,
the Working Group had to name and define some basic
trackable object classes. Some of these classes are
shown in Figure 2.
For each class a set of attributes is defined. Also links
to other object classes are described. The definitions of the
object classes can be found in Appendix A.
The list of trackable objects in this report is not complete.
Some other objects may be used by local systems
working on a specific step of the newspaper production. It
will be up to the newspaper companies to decide which
objects are important for them to be tracked, especially on
a global level. Therefore, according to specific needs, this
object list can easily be extended.
4.5 Attributes and links
Changes in object attributes are also important tracking
information and need to be communicated. Therefore,
some basic attributes for each object class had to be defined.
Objects can also be linked to other objects. The links
have to be transmitted to fix the object path. It is possible
to add, remove and change links between objects.
It is difficult to think of all the attributes that will
prove necessary on different occasions. Therefore, it is
highly probable that different implementations will come
up with additional attributes. Different implementations
could add attributes that they find necessary in an easy
and flexible way. Valid and interesting attributes would
need to be registered with Ifra for the next versions of the
specification.
Object Name
Object Class
City South
Edition Version
Insert A
Product
Morning Edition
Edition
Main
Product
The Times of IFRA
970930
Issue
City North
Edition Version
Insert B
Product
Main
Product
Evening Edition
Edition
City
Edition Version
Main
Product
Page 1
Page 2
Page 3
Page 1
Page 2
Page 3
Page 1
Page 2
Page 3
same
content
Page 16
Page
Page 16
Page
Page 24
Page
Figure 4: An example of the hierarchical structure of objects in newspaper
production.

4 The IfraTrack object concept
11
© 2002 Ifra, Darmstadt
Ifra Special Report 6.21.3
Production Planning
Ad booking
Reservations
Reservations
Edition
planning
Issue, Edition
(Images, Ads, Ads,
Articles and and Logical
pages are are Elements
as as defined in in the the
recommendation)
specification
Prepress
Ad.
production
Images
Image
production
Images
Editorial
production
Ads
Ads
Images
Images
Articles
Articles
Page
layout
Page
assembly
Page
Forme
assembly
Logical page
Forme description
Forme bitmap
Ripping
Forme bitmap
Computerto-plate
Plates
Recording
Film
Page Output & Platemaking
Platemaking
Plates
Press
Reels
Reel
handling
Reels
Product
Printing
Product
Product
Storage
Product
Mailroom &
Distribution
Bundle
Drop
Route
Mailroom & Distribution
Van
Figure 3: Basic model of newspaper production (the structure of the pre-press department is only an example of a possible organisation). The boxes represent
activities and objects are processed by these activities.

12
5 States of objects
Ifra Special Report 6.21.3
© 2002 Ifra, Darmstadt
5 Status of objects
5.1 Background
The main reason to send tracking messages is the
change of object status. By associating events with objects
and their status, a tracking system can follow the progress
of the production. An object can have a great number of
state values. If we take the example of an ad in the prepress
department, the status values can be: “registered”,
“booked”, “planned”, “positioned”, “assembled”, “approved
by the customer”, “proofed”, “instances placed on a page”,
“all instances placed”, “cancelled”, “credit OK”, “invoiced”,
“paid”, “archived”. A list of object states would need to be
defined for each object class, which would be a difficult
task. In order to keep the definition as simple as possible,
the Working Group has agreed upon a state structure that
does not go into a great deal of detail, but allows for the
communication of essential tracking information between
systems.
5.2 Workflow status
Each activity in newspaper production can have several
subactivities and each object can be processed by several
subactivities or activities. The sequence of activities that
an object passes through defines the workflow of that object,
and each activity in the workflow defines a workflow
step.
Associated with the workflow steps are the workflow
status of the object. An object does not necessarily need to
complete one workflow step before starting the next. This
means that an object can be active in more than one workflow
step at once. Consequently, an object can have a different
status in different workflow steps at the same time.
To avoid these problems, the workflow step will have
to be transmitted in the tracking message together with the
new status of the object. If no workflow steps are defined,
“production” should be used as default.
5.3 Dual state concept
The Working Group has defined a status concept and
according to this definition, each workflow status for an
object is dual, i.e., consists of a process state and a schedule
status. The process status can be “not started”, “in
progress” or “completed”. It can also be temporarily “on
hold” or “aborted” without completion. The schedule status
can be either “in time” or “late”. The state “warning” has
been added as an additional schedule status, and means
that the object is not late yet but soon will be.
Figure 3 shows the possible status for an object and
the possible changes between states. It has to be noted that
an object cannot go from the status “in progress” to the
state “not started”. If this happens, a new object has to be
created. This is the case in the mailroom, for example,
when a bundle is damaged and has to be produced again.
Not Started
Process state
Schedule state
In Time
In Progress
On Hold
Warning
Figure 5: Each trackable object has a dual state.
Late
Completed
Aborted
These basic status reports are sufficient for the exchange
of information between systems. Local systems will
have a much more detailed status structure but do not
need to communicate all this information to other systems.
5.4 Deadlines
To extend the functionality of the IfraTrack specification,
any process status of an object can be associated with
a deadline, specifying when the process state should have
reached a specific value. If the value have not been
reached by time of the deadline, the corresponding schedule
state will be set to “late” (or to “warning” depending
on the deadline statement). This means an object not only
contains information about its current status, but may also
contain schedule information.
5.5 Resources
Two object classes in the model can be considered to
be resources, “Van” and “Reel”, but a genuine resource
model is not included in the IfraTrack specification. However,
to allow some simple tracking of other resources,
local extensions to the model can be made where resource
objects are included. It is possible to associate resource objects
to any state change or when setting a deadline, to indicate
that the resource was (or is planned to be, in the
deadline case) involved in the event. See Appendix B.

© 2002 Ifra, Darmstadt
Ifra Special Report 6.21.3
6 Message format
13
6 Message format
6.1 Background
One of the first requirements for the tracking messages
exchanged by different systems was that they should be as
simple as possible. For that purpose, the Working Group
decided that these messages should be simple text strings.
It should be possible to read and analyse the messages that
are sent and received.
A tracking message should contain the following information:
> Time. The time when the message was generated.
> Message sender. Information about the system
generating the message and about the supplier of that
system.
> Object identifier. A unique identifier of the object
concerned with the tracking message. The identifier
must be either globally unique, or unique within a
specified system. In the latter case the system together
with the local identifier will function as the object
identifier.
> Object data. The object information transmitted in the
message. The object data may include status change,
attributes, links, deadlines and resource information.
It has been proposed that the IfraTrack specification
should include a naming convention for the uniqueness of
the object identification. A naming convention for the objects
would be helpful, especially when automatic identification
techniques (like bar coding) are used. The task of
defining naming conventions for the objects could be a future
task for Ifra. For the time being, it is up to the system
suppliers to uniquely identify the objects concerned by the
tracking messages.
6.2 The Ifra Message Format
For this version of IfraTrack the Working Group has
decided to abandon the existing proprietary message format
in favour of a new XML based format. Since XML is
becoming a widespread standard for exchanging various
kinds of information it is now the natural choice for formats
such as this. The time to get started with an implementation
of IfraTrack will decrease since no extra energy
must be spent to understand the messaging format, and all
energy can be spent on solving the actual problems. An
additional benefit of using XML is the wide range of
parsers and validators available for XML.
XML is a universal format for structuring information.
Today most new data formats where compact coding is not
of vital importance are based on XML. To base a messaging
format on XML is today the natural choice. Using XML
gives several advantages. Many high-quality parsers and
tools are available which saves time and increases the
quality of an implementation, validation tools make it easy
for an IMF supplier to verify that generated messages are
correct and the use of a well-known frameworks decreases
the time required to understand the specification.
XML Schemas is a new, better way to describe XML
structures than the DTDs used until now. With Schemas it
is possible to extend the model in a controlled way, and to
have all restrictions that should be imposed upon the messages
defined in a computer readable format. It also provides
possibilities to separate the tracking data from the
messaging data better than before.
The new Ifra Message Format (IMF) is using XML
schemas to make it easier to extend and adapt the model
for specific newspapers in a controllable way. Using XML
namespaces in conjunction with the schema feature of “refinement
by extension” makes it possible to write a local
adjustment for one specific newspaper, and still make the
resulting XML pass validation tests.
A complete description of the Ifra Message Format is
given in Appendix B and the standard IMF schema specification
is included as Appendix C.

14
7 Message exchange mechanism
Ifra Special Report 6.21.3
© 2002 Ifra, Darmstadt
7 Message exchange mechanism
7.1 Background
To exchange tracking information, tracking systems require
an exchange mechanism. This mechanism should define
how the message is delivered from the sender to the
receiver(s).
Note: the ‘sender’ is the generator of the message, the
‘receiver’ is any system that wants to register the message.
Since the approach of the Working Group has been one
of simplicity, the exchange mechanism had to be easy to
implement. It therefore required high level, well accepted,
industry standard building blocks. At the same time the
exchange mechanism had to work independently of status
to assure synchronisation between systems.
Nevertheless this chapter contains a description of
three possible mechanisms for explanation purposes: a
central relational database approach, a file exchange approach
and a TCP/IP socket approach. Other possible exchange
implementations are (list is not complete):
> e-mail
> TCP broadcast
> object request brokers
Not defining an exchange mechanism implicates more
work to be done during the installation of tracking system
interfaces. Prior to the implementations of those interfaces,
decisions will have to be made what the best way is, for
that particular case, to exchange tracking messages.
Config.
File
Production
Event
IMF
Generator
IMF
File
IMF
Parser
Data Structure
Semantics
of system B
Tracking System A
(sender)
Tracking System B
(receiver)
Database
of
system B
7.2 Example 1 – Central database approach
This approach is created around a central relational,
and most likely SQL-based, database. All senders transmit
their tracking messages to this RDBMS using SQL insertstatements.
All senders know how to access the database (database
name, passwords, table name, network addresses) and have
appropriate authorisation. Senders run an SQL-client to do
the insert.
The datamodel of the central database consists of only
one table having a sequence number column and a message
column which contains the entire tracking message
conforming to the IMF syntax. The sequence number secures
each record to be uniquely identified.
RDBMS
Figure 6: An example of a possible implementation.
There are several possibilities to implement an exchange
mechanism meeting the requirements stated above.
However, the Working Group has decided not to recommend
a certain mechanism being the preferred solution.
The reason for this lies in the fact that every possible
mechanism has specific pros and cons depending on:
> network topology
> preferred network software and software
already in use
> installed systems
> other local preferences
(databases, system architecture, network specifics, etc.)
DB insert
Local Tracking
System
Global Tracking
System
select
Local Tracking
System
Figure 7. Illustration of a possible implementation of the central relational
database approach.
In this example the receiver can fetch tracking information
by accessing the table using sql select-statements.
After fetching a message, the contents can be parsed locally
by the receiver.

7 Message exchange mechanism
15
© 2002 Ifra, Darmstadt
Ifra Special Report 6.21.3
7.3 Example 2 – File exchange approach
In the file exchange approach, every sender has a list
of receivers to which their tracking messages should be
sent.
File transfer
Local Tracking
System
Global Tracking
System
The tracking message is a flat-file which is sent to a
specified file directory on the network for each registered
receiver. A file can contain one or more tracking messages.
It can be appended to existing files on the receiver or can
be copied as a single message to all its receivers.
Every receiver decides for itself what to do with a received
tracking message. For example, it can leave it a
flat-file and add it to its log-file or it can parse the message,
convert it into SQL and add it to its local database.
7.4 Example 3 – TCP/IP socket approach
In this approach TCP/IP socket communication is used
for the message exchange. This approach allows sending
messages to a central server (as in the central database approach)
or to a list of receiving systems (as in the file exchange
approach) without knowing anything about the receiving
system(s) except the IP number and a port number.
The systems must, however, be connected to a TCP/IP network.
The suggested protocol for sending an IMF message
with this approach is the following:
open socket at (server host, port)
server: HI
client: PUTIMF
client:
client:
client:
server: OK/ERR
client: BYE
server: BYE
close socket
File system
File
transfer
Local Tracking
System
Figure 8: Illustration of a possible implementation of the file exchange
approach.
where is any character sequence not in
the IMF message, and is the IMF message. If
the command was successful the server will send “OK”,
otherwise “ERR” to indicate an error.
The protocol is not case sensitive, and each line should
be separated by a new-line character.
Between the “HI” and “BYE” parts any number of commands
could be sent before closing the socket. Other commands
than “PUTIMF” could be defined if needed. This approach
allows future expansion for control messages, since
the socket can be used for two-way communication.
It is also possible to use an HTTP POST request to send
IfraTrack messages. The suggested port to use is the standard
HTTP-port 80. The receiving program could be for
example a CGI-script or a stand-alone program capable of
receiving HTTP requests. The use of HTTP can be useful if
corporate security does not permit traffic other than to
web servers. The exact URI to the receiving resource
should be configurable on the client. The suggested variable
name to use is MESSAGE.
7.5 Time synchronisation between systems
There are three time stamps in the processing of an
IMF message:
when the event occurred: this time comes from the
time section of the message and is generated by the originator
of the message.
when the message was delivered to the receiver: this
time comes from the receiving system.
when the IMF file was processed by the receiver: this
time comes from the processing program.
In addition, an optional time-zone specifier can be
added to a message if it is sent over different time-zones.
If time synchronisation is needed between the different
systems, the sender and the receiver of a message should
have the same time reference. The problem of exact time
synchronisation between different systems is not an easy
task. However, in most cases exact synchronisation is not
needed. Then it might be enough to use, for example, a
time synchronisation utility based on NTP, the Network
Time Protocol. NTP is a protocol that allows you to synchronise
a number of computers to a time server on the local
network, or on an external network through the Internet.
NTP guarantees a maximum time difference of 1 second
between different computers.

16
8 Using and maintaining the specification
Ifra Special Report 6.21.3
© 2002 Ifra, Darmstadt
8 Using and maintaining the specification
8.1 Exchanging information between
production tracking systems and
building global tracking systems
The IfraTrack specification should be a useful tool
within newspaper production departments to exchange
topical tracking information. As already stated, this specification
should enable newspapers to create links between
tracking systems in the various departments and also to
install global production tracking systems. It will also be a
new opportunity for system suppliers to offer global tracking
systems that will be compatible with existing systems.
It will be up to each supplier to offer the most user-friendly
and efficient system.
As a result of the application of IfraTrack, it may be
possible to achieve integrated tracking in newspaper production.
This means better control of the entire process,
the possibility to optimise production, and the possibility
to significantly improve productivity. This, in turn, can
lead to better economy and competitiveness for the newspapers.
8.2 Subscribing to the specification and use
of the IfraTrack logotype
Ifra will be the contact body for the companies wishing
to subscribe to the specification.
Registered companies will be allowed to use the
IfraTrack logotype when advertising for their products.
This logotype is a proof that the product is compatible
with the IfraTrack specification, which means that the system
will be able to communicate and exchange information
with other systems in the newspaper production environment.
8.3 IfraTrack on the Web
There is on-line information about IfraTrack available
on the World Wide Web. All interested people concerned
with the development of IfraTrack compliant systems can
have access to this service under on Ifra’s website:
http://www.ifra.com.
The pages about IfraTrack can be reached under “research
& consulting” or from the “site index” at the navigation
bar, as well as directly under
http:// www.ifra.com/website/ifra.nsf/html/ifratrack
8.4 Registering new object classes and attributes
Ifra will be responsible for registering new object classes
and attributes. New lists of object classes and attributes
will be published when needed.
Companies wishing to register new object classes or attributes
should contact Ifra Research Department.
8.5 Ifra’s role in maintaining the specification
Depending on the speed of development and the acceptance
of IfraTrack, there will be a need to maintain the
specification. Some adjustments will have to be made to
the definitions and hopefully the specification will continue
to evolve.
Ifra will make sure that the specification stays up-todate.
This follow-up could be done by forming small focus
groups for different topics, and organising regular meetings
with interested parties.
Figure 7. The IfraTrack logotype.
The IfraTrack logotype can be obtained from Ifra Research
Department. Ifra will not perform any IfraTrack
compliance check or validation. This will be the responsibility
of each company.

© 2002 Ifra, Darmstadt
Ifra Special Report 6.21.3
9 Future extensions to the specification
17
9 Future extensions to the specification
9.1 Possible extension into scheduling and control
Efficient production tracking is only a first step in
making newspaper production an industrial process that
can be efficiently monitored and controlled in the same
manner as other industrial processes. Tracking is a necessary
basis to avoid or correct problems during the production.
Newspapers will have to move towards adaptive production
control and management.
Production control means the active rescheduling of
worksteps and the reassignment of resources in case of a
deviation from a schedule. A production control system
would be able to solve problems in minimising delays and
costs. In the case of a major rescheduling operation, the
system would ask for approval and advice from an operator.
For active production control to be possible, the control
system requires detailed information on the product to
be produced, the worksteps involved, the resources available
and the default production schedules. In a heterogeneous
environment, involving systems from different
manufacturers, this information has to be transmitted between
the control systems in a structured and standardised
manner. The definition of these mechanisms could be the
objective of future initiatives and efforts.
Production management involves the collection and
analysis of data on production runs and production costs,
covering the entire newspaper production process. This information
will be used by production and general management
to support process improvement and strategic planning.
In this area too, standardised means of exchanging
information are required.
In the latest versions of the IfraTrack specification,
some features have been added to prepare the specification
for future extensions. A resource tracking mechanism has
been included to encourage users of IfraTrack to go beyond
tracking. In this version there is not yet a resource
model to go with the resource tracking mechanism, but if
there is need for one, it should be included in the future.
The new XML-based message format will be a good
platform for future enhancements.
The TCP/IP socket approach for message exchange,
which is introduced in this version of the specification, is
another example. It could be used for two-way communication
in a possible future control mechanism.
Below is a list of features that was considered during
the work of the 2.0 and 3.0 specifications, but were omitted
due to lack of time.
9.2 A more generalised model
During the work with the specification the Working
Group has had discussions about generalising and extending
the model to other areas similar to traditional newspaper
production. Interesting areas could be catalogue production
and electronic publishing. Newspaper companies
will most likely publish both printed and digital products
in the future, and therefore need a tracking model capable
of multichannel publishing.
The schema approach in the new IfraTrack specification
makes it possible to extend IfraTrack to completely
new contexts, such as TV news production [Hedin, Fällström
2001].
9.3 Further integration with JDF
The Working Group (or a future focus group) should
look at to the JDF specification, to see how the use of the
IfraTrack specification could be further enhanced. See appendix
F.
9.4 Version control
A mechanism for version control of objects is not included
in this version of IfraTrack. This would be needed
to keep track of objects when handling more then one version
of an object, for example when an article is updated.
9.5 An extended distribution model
In the current IfraTrack specification the distribution
model ends when bundles are delivered to delivery points
along the distribution route. By adding objects representing
carrier districts and carriers to the object model, detailed
tracking of the delivery of newspapers to the subscribers
is possible [Rehn et al, 2000].

18
9 Future extensions to the specification
Ifra Special Report 6.21.3
© 2002 Ifra, Darmstadt
9.6 IfraTrack queries
When using multiple systems within the same newspaper,
there is sometimes a need for an active communication
between the different subsystems in the sense that one
system may request information from another. To enhance
this kind of communication, a standard for the syntax and
content of queries is important and this may be an extension
to the Ifra Message Format in the future.
A possible channel of communication is for a later step
in the workflow to ask previous system about specific information.
The printing house may send a query to get an
estimation on how many colours to use. For plate production,
it might be interesting to ask for the status or time
status of the pages to be placed on the plate.
Currently, IfraTrack information is available to a system
only by processing and parsing all IfraTrack messages
without selection.
9.7 Cost estimation
Another area that is not covered by the IfraTrack specification
is the exchange and gathering of cost information
and cost estimations. This may include estimated costs for
colours of prints, production costs of ads, estimated distribution
costs due to a delay or a larger product and more.
This kind of information might be included within the
IfraTrack message as attributes to different objects, by separate
cost objects or included in a format for IfraTrack
queries.
Literature
Hedin B, Fällström F
2001 “Extending IfraTrack for use in General Media
Production”, to be published in the Proceedings of
TAGA 2001, San Diego, 2001.
Rehn J, Stenberg J, Hedin B, Fällström F
2000 “Improving Metropolitan Newspaper Home Distribution”,
2000.
Thoyer B
1995 “IfraTrack: a recommendation for the interchange
of status information between local and global
tracking systems in newspaper production”, Version 1,
Ifra Special Report 6.19, Darmstadt, Germany.
Thoyer B
1996 “IfraTrack: a recommendation for the interchange
of status information between local and global
tracking systems in newspaper production”, Version
1.1, Preprint of an Ifra Special Report, Darmstadt, Germany.
Nordqvist S
1998 “IfraTrack 2.0 – Executive summary. A specification
for the interchange of status and management information
between local and global production management
systems in newspaper production”, Ifra Special
Report 6.21.1, Darmstadt, Germany.
Fällström F
1998 “IfraTrack 2.0 – a specification for the interchange
of status and management information between
local and global production management systems
in newspaper production”, Ifra Special Report
6.21.2, Darmstadt, Germany.

Appendix A – IfraTrack object classes
19
© 2002 Ifra, Darmstadt
Ifra Special Report 6.21.3
Appendix A – IfraTrack object classes
This section outlines the attributes and possible relationships
for each of the supported IfraTrack classes. Links
between classes are named, so that more than one link
type between to classes can be defined. Links are always
allowed to be empty since the known structure can be incomplete.
In the following, the relations between objects are
specified as:
1➔1 One To One
1➔n One To Many
n➔1 Many To One
n➔n Many To Many
Attributes types are specified in brackets after the attribute
name. For non-simple attribute types, the type is
defined at the end of the class definition e.g. for a product
class; the ProductionType attribute can be one of
“main_run”, “pre_run” or “external”.
The OPENLIST specifier means that the attribute is a
variable length array of the given data type. Open lists
may have zero length.
Links are not specified as OPENLIST attributes. It is
likely that some systems may implement them as so. However
this will not always be the case – in particular objectoriented
systems are unlikely to implement them this way.
The link destination class and relation are specified in
brackets after the link name.
Issue
Edition
EditionVersion
Van
Route
Drop
Bundle
Symbols
One and
only one
One or many
Reel
Issue
An issue is the top-level object class of a publication
for a single publishing date.
ATTRIBUTES Name (STRING), Date (DATE)
LINKS
EditionsLink (Edition, 1➔n),
ElementsLink (Element, n➔n)
Date should be an XML formatted date (YYYY-MM-DD).
Edition
An issue may be divided into different editions, for example
a morning edition and an evening edition. Also a
newspaper is usually made of different local editions.
ATTRIBUTES
LINKS
Name (STRING)
IssueLink (Issue, n➔1),
EditionVersionsLink
(EditionVersion, 1➔n)
EditionVersion
The concept of “edition version” had to be defined by
the Working Group to be able to track special cases that
can occur in newspapers. The typical use of the edition
version class is for zoning. For example, an advertiser decides
to distribute an insert in the newspaper to the readers
living in a particular city or area only. These readers
will get the same main product of the newspaper as other
readers living outside this area, but the inserts will differ.
They get the same edition but different edition versions of
the newspaper.
Exactly how to divide a newspaper into editions and
edition versions will be dependent on how the newspaper
is organised, and it is up to each implementation to make
the distinction.
ATTRIBUTES
Name (STRING),
PlannedCopies (INTEGER),
ActualCopies (INTEGER)
Product
PrintingJob
LINKS
EditionLink (Edition, n➔1),
Page
ProductsLink (Product, n➔n),
Department
Position
RoutesLink (Route, n➔n),
Element
FormeDescription
CTP
FormeBitmap
Figure 10: Data model with the different object classes.
Plate
Film
BundlesLink (Bundle, 1➔n)
PlannedCopies is the total number of copies planned
for the edition version.
ActualCopies is the number of produced copies, complete
with inserts and supplements included, at a particular
moment.

20
Appendix A – IfraTrack object classes
Ifra Special Report 6.21.3
© 2002 Ifra, Darmstadt
Product
A product is a collection of printed pages. It can be a
newspaper, a section of the newspaper, a supplement that
has been pre-printed or an insert that has been printed externally.
ATTRIBUTES
LINKS
TYPEOPTS
Name (STRING),
ProductionType (TYPEOPTS),
PlannedCopies (INTEGER),
ActualCopies (INTEGER),
Weight (INTEGER),
NoOfPages (INTEGER)
EditionVersionsLink
(EditionVersion, n➔n),
PrintingJobsLink
(PrintingJob, 1➔n),
PagesLink (Page, n➔n),
DepartmentsLink
(Department, n➔n)
“main_run”, “pre_run”,
“external”
ActualCopies is the total number of good copies of this
product (the sum of all its printing jobs) at a particular
moment.
Weight is the weight of a single copy in grams.
Page
A page is a complete page in the pre-press department
as it will be printed (i.e. with a page number).
ATTRIBUTES
LINKS
TYPEOPTS
COLOUROPTS
Name (STRING),
PageNumber (INTEGER),
Colours
(OPENLIST(COLOUROPTS)),
PageFormatType (TYPEOPTS),
Image (IMAGE)
ProductsLink (Product, n➔n),
ElementsLink (Element, n➔n),
FormeDescriptionsLink
(FormeDescrition, n➔n),
SubElementPositionsLink
(Position, 1➔n)
“tabloid”, “broadsheet”
“c”, “m”, “y”, “k”, “spot”
IMAGE is a complex element type either including an
encoded image or a reference to a separate file containing
the image.
Element
An element is a part of a page, a complete page or a
spread. An element can be of the following types:
text
image: black & white or a colour picture that has been
scanned.
graphic: object of lineart type. It can be a logo or an
infographic created with an illustration software.
reservation: empty space reserved for further use. It
can be used to put an ad or an article that have been
planned.
composed: an element that contains sub-elements. For
example, an article can be described as an element containing
text and graphics elements.
complete page: an element covering a complete page.
This is a special case of composed element.
spread: an element covering a spread. A spread is a
special case of composed element.
ATTRIBUTES
LINKS
ETYPEOPTS
CTYPEOPTS
COLOUROPTS
OPIOPTS
Name (STRING),
ElementType (ETYPEOPTS),
ContentType (CTYPEOPTS),
Colours
(OPENLIST(COLOUROPTS)),
OPIStatus (OPIOPTS),
Shape (OPENLIST(INTEGER)),
Image (IMAGE)
PagesLink (Page, n➔n),
ContainerElementsLink
(Element, n➔n),
SubElementsLink
(Element, n➔n),
IssuesLink (Issue, n➔n),
FormeDescriptionsLink
(FormeDescription, n➔n),
DepartmentsLink
(Department, n➔n),
SubElementPositionsLink
(Position, n➔n),
PositionsLink (Position, n➔n)
“text”, “image”, “graphic”,
“reservation”, “composed”,
“complete page”, “spread”
“editorial”, “advertising”
“c”, “m”, “y”, “k”, “spot”
“available”, “not_available”
Shape is a polygon described as a list of integer coordinates
(x1, y1, x2, y2, ...). The values are in millimetres.
When OPIStatus is “available”, it means that the highresolution
file is available on the server.
IMAGE is a complex element type either including an
encoded image or a reference to a separate file containing
the image.
When tracking pages not yet positioned in a product,
i.e., pages without page numbers, it is suggested to use the
element class for this purpose, with the ElementType attribute
set to “complete page”.

© 2002 Ifra, Darmstadt
Ifra Special Report 6.21.3
Appendix A – IfraTrack object classes
21
Position (optional)
The position class allows an element to be positioned
on a page or on a higher level element. By making the Position
to a class rather than an attribute, an element can
have different positions on different pages. Instances of
the position class is not part of the main link chain and
can be ignored by any system not wanting to deal with
them, without breaking the main link chain in the model.
ATTRIBUTES
LINKS
Name (STRING), X (INTEGER),
Y (INTEGER),
Layer (INTEGER),
Shape(OPENLIST(INTEGER))
ContainerPageLink
(Page, n➔1),
ContainerElementLink
(Element, n➔1),
SubElementLink
(Element, n➔1)
X and Y defines the origin in millimetres relative to the
object onto which the element is positioned.
Shape allows an element to be transformed from its
original shape. The shape attribute is a polygon described
as a list of integer coordinates (x1, y1, x2, y2, ...) in millimetres
relative to the origin.
Layer decides which object should be on top when
overlapping. Higher values will be put on top.
Department (optional)
A department is used for logical grouping of elements
considering their contents. An example of a department is
the “Sports” department. This object class is included
mainly for convenience. Like the position class, instances
of the department class can be ignored by any system not
wanting to deal with them, without breaking the main link
chain.
ATTRIBUTES
LINKS
Name (STRING)
ProductsLink (Product, n➔n),
ElementsLink (Element, n➔n)
FormeDescription
A forme description is an electronic file corresponding
to one (or several) page(s) or one (or several) element(s)
ready to be ripped.
ATTRIBUTES
LINKS
COLOUROPTS
Name (STRING),
Colours
(OPENLIST(COLOUROPTS))
PagesLink (Page, n➔n),
ElementsLink (Element, n➔n),
FormeBitmapsLink
(FormeBitmap, 1➔n)
“c”, “m”, “y”, “k”, “spot”
There is a relation between an element and a forme description
in the case that an element is mounted manually
on the page after the typesetting, or if the element is to be
ripped separately from the page.
FormeBitmap
A forme bitmap is a ripped separation of a page or element.
For example, the ripping of a four colour-page will
create four forme bitmaps. It can also be the result of the
transmission of a page that has been faxed.
ATTRIBUTES
LINKS
COLOUROPTS
Name (STRING),
Colours
(OPENLIST(COLOUROPTS))
FormeDescriptionLink
(FormeDescription, n➔1),
FilmsLink (Film, n➔n),
PlatesLink (Plate, 1➔n)
“c”, “m”, “y”, “k”, “spot”
In case of computer-to-plate production, the list of
films should be replaced by the list of plates.
Film
A film is the result of the imagesetting of a forme
bitmap.
ATTRIBUTES
LINKS
COLOUROPTS
Name (STRING),
Colour (COLOUROPTS)
FormeBitmapsLink
(FormeBitmap, n➔n),
PlatesLink (Plate, n➔n)
“c”, “m”, “y”, “k”, “spot”
Plate
A printing plate is the result of the exposure of one or
several films. The plate is the physical element transmitted
from the pre-press to the press department of the newspaper.
ATTRIBUTES
LINKS
SIZEOPTS
COLOUROPTS
Name (STRING),
PlateSize (SIZEOPTS),
Destination (STRING),
Colour (COLOUROPTS)
FilmsLink (Film, n➔n),
FormeBitmapLink
(FormeBitmap, n➔1),
PrintingJobsLink
(PrintingJob, n➔n)
“single”, “double”
“c”, “m”, “y”, “k”, “spot”

22
Appendix A – IfraTrack object classes
Ifra Special Report 6.21.3
© 2002 Ifra, Darmstadt
Blind plates are not tracked with this model.
In case of computer-to-plate production the list of
films should be replaced by the list of forme bitmaps.
Destination is a string and may contain information
about printing unit, cylinder couple, zone group,
front/back. It is up to the local system to define the naming
convention.
PrintingJob
A printing job is defined as one run on one press without
planned plate changes. The change of plates for the
production of a local edition will be the starting point of a
new printing job. Some unplanned plate changes (when a
plate is damaged for example) can be made within a printing
job.
Unused is the paper length (in meters) remaining on
the reel at a particular moment.
Van
A van describes the load of a distribution vehicle.
ATTRIBUTES
LINKS
Name (STRING),
MaxWeight (INTEGER)
RoutesLink (Route, 1➔n)
MaxWeight is the maximum weight in kg acceptable
for the van.
Route
A route is a set of delivery points for an edition version.
A route is a mailroom object.
ATTRIBUTES
LINKS
Name (STRING),
PressSection (STRING),
PlannedCopies (INTEGER),
ActualCopies (INTEGER),
Waste (INTEGER),
PressSpeed (INTEGER)
ProductLink (Product, n➔1),
ATTRIBUTES
LINKS
Name (STRING)
VanLink (Van, n➔1),
EditionVersionsLink
(EditionVersion, n➔n),
DropsLink (Drop, 1➔n)
Drop
A drop is a delivery point in a route.
PlatesLink (Plate, n➔n), ReelsLink
(Reel, n➔n)
PlannedCopies is the total number of planned copies
for the printing job.
ActualCopies is the number of good copies at a particular
moment.
Waste is the number of waste copies.
PressSpeed is an integer expressed in copies/hour at a
particular moment. This information comes from the press
control system or from a copy counting system.
Reel
A reel is a new or a partly used paper reel.
ATTRIBUTES Name (STRING),
PaperType (PTYPEOPTS),
ReelWidth (WIDTHOPTS),
Unused (INTEGER)
LINKS
PrintingJobsLink
(PrintingJob, n➔n)
PTYPEOPTS “standard”, “special”
WIDTHOPTS “1/4”, “1/2”, “3/4”, “1”
ATTRIBUTES
LINKS
Name (STRING),
NoOfCopies (INTEGER)
RouteLink (Route, n➔1),
BundlesLink (Bundle, 1➔n)
NoOfCopies is the number of copies to be delivered to
the drop.
Bundle
A bundle is a group of copies bound together in the
mailroom. An individual copy is a special case of bundle.
ATTRIBUTES
LINKS
Name (STRING),
NoOfCopies (INTEGER)
DropLink (Drop, n➔1),
EditionVersionLink
(EditionVersion, n➔1),
ContainerBundleLink
(Bundle, n➔1),
SubBundlesLink (Bundle, 1➔n)
PTYPEOPTS is the paper type. “standard” is for standard
newsprint and “special” is for all other grades.

© 2002 Ifra, Darmstadt
Ifra Special Report 6.21.3
Appendix B – The Ifra Message Format
23
Appendix B – The Ifra Message Format
The Ifra Message Format (IMF) is defined as an XML
schema.
An IMF message is an individual message, which conforms
to the IfraTrack IMF specification. IMF messages
may be transmitted via the file system, through databases,
or using other methods (see Message Exchange Mechanism).
When sending IMF messages via the file system,
then an IMF file is a file, which contains one or more IMF
messages.
Case sensitivity and word spacing in IMF messages
All identifiers, keywords, elements, attributes and enumeration
values are case sensitive.
Identifiers belonging to the message format are written
in lower case with an underscore as word separator. Examples:
object_uid, planned_resources.
Names in the IfraTrack data model, like object classes,
attributes, activities and link names are written in lower
case where each word (including the first) starts with an
upper case character. Examples: PrintingJob, ActualCopies.
Enumeration values are written in lower case with an
underscore as word separator. Example: in_progress,
main_run
When extending the model it is suggested that these
rules are followed for any new names and values introduced
to the data model.
Non-standard characters
Non-standard characters should be encoded as Unicodes
within an IMF message. In XML a Unicode character
is explicitly encoded as “&#n;”, where n is the Unicode for
the character.
For example the character “å” is encoded as “å”,
and the word “plåt” (plate in Swedish) would be encoded
“plåt”.
Plåt
Message structure
A message consists of a head and a body.
…
…
Message head
The message head includes a version, source, timestamp
and an optional message id. An optional meta tag
has also been included for any non-standard information.
3.0
1997-10-06T00:11:00+02:00
174711
Apple
Version
The version element indicates which version of
IfraTrack the IMF message adheres to. In the current version,
this will be:
3.0
Source
The source element contains information on the application,
which generated the IMF message. This is broken
down into a unique supplier id (to be supplied by Ifra), and
a name which identifies the copy of the application (e.g. if
there are 10 QuarkXPress workstations, the applications
might be “QXP-01”, “QXP-02”, ...).
The supplier and application is defined as attributes to
the source element. The element content should be empty.
Time stamp
The timestamp is the local time of the system sending
the message. The time stamp describes when the object updates
in the message body occurred. If messages are sent
over different time zones an optional time zone can be
specified also. An example:
1997-10-06T00:11:00+02:00
Message id
An optional message id has been added to the message
head. The message id is a string that the sender of the message
may use to identify the message in case of a detected
error.
174711

24
Appendix B – The Ifra Message Format
Ifra Special Report 6.21.3
© 2002 Ifra, Darmstadt
Meta tag
The meta tag is optional and can be used to add any
non-standard information to the message, like a comment
(that should survive the parser) or a parser directive.
A name attribute in the meta tag should be included to
describe the information.
Apple
Message body
As the purpose of IMF messages is to exchange information
on database objects to enable production tracking
in a multi-vendor system environment, it is necessary for
the IMF format to enable the specification of details, status
and structure of an object. To do this, the IMF format uses
the concept of attributes, activity states, links and schedules.
The definitions below indicate how these terms are
used in the context of the IfraTrack IMF specification only.
The message body contains a number of object elements.
The object element identifies the object and what is
to be done to it. There can be zero, one or many object elements
in an IMF message.
An object element always consists of an action, an object
class and an object reference. In addition, attributes,
activities, links and schedules can be added to the object
element.
…
…
…
…
…
Action
The action is an attribute to the object element. The action
indicates what to do with the object. There are five
possible operations: “create”, “put”, “modify”, “delete” and
“purge”. The following definitions are used:
Create indicates that a new object should be created; if
the object already exists then the operation should
fail/generate an error.
Put indicates that an object should be created if it does
not already exist, or modified if it does exist.
Modify is used to modify an object only if it exists already.
Delete indicates that an existing object should be deleted;
if the object does not exist then these operations
should fail/generate an error.
Purge indicates that an object should be deleted if it
exists; if the object does not exist nothing is done and no
error is generated.
Object class
The first element within the object element specifies
the object class. The object class name is an empty element
(equivalent to abstract_object), that can be used both in
the object element and in the object path section.
Object reference
An object reference is used to identify the object to
which the message refers. This is done by providing a full
description of the object’s position in the IfraTrack data
model, or by providing a unique identifier for the object in
the generating application.
A position description can be used when the position
of an object within the IfraTrack hierarchy is known; if it
is not, then a unique identifier must be provided. This
unique identifier is specified in an object_uid element, and
the position description in an object_path element. Either
an object_uid element or an object_path element must follow
directly after the object class name element.

© 2002 Ifra, Darmstadt
Ifra Special Report 6.21.3
Appendix B – The Ifra Message Format
25
Unique object identifier
The object_uid element contains a local_id element.
The local id uniquely identifies the object in the tracking
system, which sends the message. As an IMF header contains
a source element that uniquely identify the tracking
system which generated the message, as long as the local
id provided is genuinely unique within this system, it can
be considered to be globally unique. At some stage, a link
will be made between this object, and some other object(s),
at which stage it becomes possible (and probably more
useful) to use the object_path.
An optional source element is allowed before the local
id within the object_uid element. Then the local id is considered
to be a unique identifier in the system specified in
that source rather than in the system sending the message.
17
Object path
An object path describes a search path of objects from
a starting point in the IfraTrack data model, through object
links down to the referred object. Each object in the path is
identified by a number (zero, one or more) of specified object
attributes.
The object_path element contains an object_path element
followed by a number (zero, one or more) of
path_link elements.
The starting point object is defined in a path_class element.
The path class includes an object class followed by a
number of attributes.
The Times of Ifra
2000-10-06
Instead of attributes an object uid can be
used instead.
Ifra_20001006
The starting point object is followed by a number of
path links describing the path down to the wanted object.
The path_link element includes a link name and object attributes.
City
Below is an example of a complete object path for the
element named “World News 1” on page 6 in the main
product of the first City edition of the newspaper “The
Times of Ifra”.
The Times of Ifra
2000-10-06
City
First
Main
6
World News 1
Attributes
An attribute contains detail of a particular feature of
an object. An attribute may be a single value such as:
City
or an open list such as:
c m y k
Some attributes have predefined value sets (enumerations),
others are unrestricted. All attributes are typed.
In an IMF message attributes are grouped together in
an attributes element. It is not necessary to specify all attributes
for an object, only those that are affected by the
message.
14322
2955
0

26
Appendix B – The Ifra Message Format
Ifra Special Report 6.21.3
© 2002 Ifra, Darmstadt
All attributes used must be defined in the schema, either
in the standard IMF schema or in a local extension.
The schema does not include information about which attributes
are allowed for each object class. This means that
attribute names are global within the schema so attributes
with the same name cannot have different value sets for
different object classes.
Activities
An activity state contains information regarding the
status of an object within a given process or workflow.
Each activity statement is encapsulated by an activity element
including a process state. Optionally a reason and
any resources used can also be added to the activity element.
Resources will be discussed separately later.
All activities must be defined in the schema. In the
standard IMF schema only one activity is specified, “Production”.
To use other activities they must be added in a
local extension.
An IMF message for a printing job might have the following
activities element:
on_hold
web break
Note that the activity “Printing” used in the example is
defined in a local extension with the name space “demo”.
Links
A link defines the relationship between an object and
other objects. For example if an element is to be used in
two different editions, then it would have two links to
page objects (which would in turn be linked to products
and edition versions).
Each link statement is encapsulated by a link element.
The link element has an attribute “action” that specifies the
link operation. Included in the link element is a link name
element followed by zero, one or more object references.
There are three different link operations; add, remove
and set, with the following meaning:
add Adds one or more links to already
existing links.
remove Removes one or more links from already
existing links.
set Sets the links to be exactly what is
specified in this operation. All
existing links not specified will be
removed.
The links element below (taken from a page update)
adds two element objects to the page and unlinks the page
from any product.
8235
8236
Deadlines
In the schedules section deadlines and planned resources
can be set.
A deadline specifies an activity or an attribute and the
value that it must have reached by a certain date and time.
It also specifies what value the schedule state should take
if the deadline is passed. Finally a level indicator indicates
the severeness of the deadline.
The deadline element consists of the activity (including
process state) or attribute (including value), the time for
the deadline, and the schedule state (including an optional
late level).
By leaving out the time element, any existing deadline
with the specified schedule state (and level) is cleared.
A printing job might have a deadline on the printing
start expressed as follows:
in_progress
2000-10-06T00:15:00+02:00
warning
in_progress
2000-10-06T00:30:00+02:00
late

© 2002 Ifra, Darmstadt
Ifra Special Report 6.21.3
Appendix B – The Ifra Message Format
27
These deadlines will set the schedule state to “warning”
if the printing is not started by 00:15 and to “late” if the
printing is not started by 00:30.
The interpretation of the level indicator is implementation
dependent and may be used for deciding how the
event should be displayed to the user. The higher level, the
more important is the deadline.
Setting deadlines on attributes only makes sense for
incremental attributes such as ActualCopies, where a deadline
can be set when the attribute should have reached a
specific value.
The example below states that at least 20000 copies
should be printed by 00:45, or the schedule state will be
set to “late”.
20000
2000-10-06T00:45:00+02:00
late
Passing an attribute deadline will not affect the schedule
state of any activity, but for the attribute itself. The object
will be late with respect to the attribute.
Resources
Resources are not included in the standard IMF
schema. However, by defining resource classes in a local
extension, handling of resources is possible, both in the
planning stage (when setting deadlines) and during production
(when changing states).
Resources are specified in a resource element consisting
of a resource class followed by an object reference. The
resource class name is an empty element (equivalent to abstract_resource).
The object reference identifies the resource.
Press 1
By adding one or more resource elements at the end of
an activity element you can specify what resources were
used for the event. Below the activity example has been
extended with a resource element describing which printing
press were used.
on_hold
web break
Press 1
Planned resources
Planned resources can be specified in the schedules
section. A planned_resources element consists of the activity
(including process state), and one or more resource elements.
The example below (taken from a printing job update)
states that the printing press named “Press 1” is planned to
be used for the printing job.
in_progress
Press 1
The resource element has an optional attribute “role”
that can be used to specify what the resource is used for.
The use of the role attribute is unspecified. In most cases
the role attribute is not needed.

28
Appendix B – The Ifra Message Format
Ifra Special Report 6.21.3
© 2002 Ifra, Darmstadt
Images
Image support is implemented as an attribute type. An
image attribute can be used for transfer of image data for
things such as page previews. The image data may either
be stored (encoded) within the IMF file or in a separate file
referred to by a path. The data format uses standard MIME
encoding. The width and height of the image are expressed
in millimetres.
In the standard IMF schema page and element objects
has an image attribute.
begin-base64 644 IfraLogo.gif
R0lGODlhPAA9APMAAP/////27//r3//ZwP/Gov+2hP+s
d/+kaP+bW/+UTv+LP/16JPpxDQAAAAAAAAAAACwAAAAA
PAA9AAAE/xDISau9ON+gu/+VMBDFkSwMAq6sQCIKI8+z
wt5UMJYn7f8MDq7jKsWASKRgGBoYZaikFDhgAkSEbLZA
6nK5Xa/4OxZiAmarGkM4KFDVtdwSlcXneECCds/LD3wT
A1OEhTMLBBkEgRIEdYaQVBmDM3eUkZg+iWeMAIuZoHYa
dZahoZsYRwx3n6aYfRZ7ohKXroaIE2kSgLOej7aEdwK6
BZWCwJGoA0sUjr2tyMETLiHGtNGGqNQUAjMFX7zYU8IH
Fj+/4kibAQLlFarpkMI2FQgyBGg6NAfMV/bYuACwW2Ch
GANlM1RUMJBOWJAKnxD2mmAQ27pu/SR0OyigY6t+Af8O
GICHzCGqCVL6QRN3kUEBCzEOjCDBb5gQdgIQFOg4YNCC
BAX2LJBpRgcBkr26JYh1cFo5XQK/CRR4QEiBBRlzBCAZ
EMAgehSKWXJ34cDJsAWgNvvhkIGFRcoUIEDQb4AJBWcp
3tm6AC+FH9pkZO0mkYFKbxWcBP32TRYDsgB+tT0boOk1
wRNanRQKBOhOCr9auoRZeFijGYF/yMwgeZoMhRQSiDac
GbGEyjSwdgB8eyPYCQlKYT59zzUN07QWUyDZ1m0FLseG
e0JtXEZV4LYl+Oi68WFY4YaFtHqpkQb5K50i+2gOa0R0
2sQto88OwA3QCqHfn93mdQZyzdUxsFTTDhewVR1lpdXG
wALkoeFDVhZspUl1kGn03mHFlZcbLAIMKIFjSc3g4QQH
mGBCDQmkqIoCKaYIhAJfyNJiDzTM9tsu8RjSHEEV5BPA
SjkeMpt3FwAZZIjWXFDLkdQJ1J18bzFpoIbWZcDOMj1l
uQwBLnTJZZZdaumlCD2FedOTI/bIAVRqFTVVLnDe9maA
PPohR3cJVGgnEzqodZuWgAYq6KCC+vnBkpmg09cBBSyz
xpOgsMgoAQMYakUki3KxhKV4ICWDpFwsw+meH34KFJdz
kppBBAA7
====

© 2002 Ifra, Darmstadt
Ifra Special Report 6.21.3
Appendix C – The standard
29
Appendix C – The standard IMF Schema
The standard IMF schema is defined as two parts. One
general part, imf-base.xsd, defining the message structure,
and one part, imf.xsd, containg all the newspaper specific
definitions.
When referring to the schema imf.xsd should be used.

30
Appendix C – The standard
Ifra Special Report 6.21.3
© 2002 Ifra, Darmstadt

© 2002 Ifra, Darmstadt
Ifra Special Report 6.21.3
Appendix C – The standard
31

32
Appendix C – The standard
Ifra Special Report 6.21.3
© 2002 Ifra, Darmstadt

© 2002 Ifra, Darmstadt
Ifra Special Report 6.21.3
Appendix C – The standard
33

34
Appendix C – The standard
Ifra Special Report 6.21.3
© 2002 Ifra, Darmstadt

© 2002 Ifra, Darmstadt
Ifra Special Report 6.21.3
Appendix C – The standard
35

36
Appendix C – The standard
Ifra Special Report 6.21.3
© 2002 Ifra, Darmstadt

© 2002 Ifra, Darmstadt
Ifra Special Report 6.21.3
Appendix C – The standard
37

38
Appendix C – The standard
Ifra Special Report 6.21.3
© 2002 Ifra, Darmstadt

© 2002 Ifra, Darmstadt
Ifra Special Report 6.21.3
Appendix C – The standard
39

40
Appendix C – The standard
Ifra Special Report 6.21.3
© 2002 Ifra, Darmstadt

© 2002 Ifra, Darmstadt
Ifra Special Report 6.21.3
Appendix C – The standard
41

42
Appendix C – The standard
Ifra Special Report 6.21.3
© 2002 Ifra, Darmstadt

© 2002 Ifra, Darmstadt
Ifra Special Report 6.21.3
Appendix C – The standard
43

44
Appendix C – The standard
Ifra Special Report 6.21.3
© 2002 Ifra, Darmstadt

© 2002 Ifra, Darmstadt
Ifra Special Report 6.21.3
Appendix C – The standard
45
type=”integer” substitutionGroup=”imf:abstract_attribu-
type=”integer” substitutionGroup=”imf:abstract_attribute”
type=”integer” substitutionGroup=”imf:abstract_attribu-
Bundle (1:N) and EditionVersion -> Bundle (1:N) —>
Bundle (N:1) —>
Element (N:1) —>
Element (N:N) —>
Page (N:1) —>
type=”imf:AbstractLinkType”
type=”imf:AbstractLinkType”
type=”imf:AbstractLinkType”
type=”imf:AbstractLinkType”
Department (N:N) and Element -> Department (N:N) —>
Drop (N:1) —>
Drop (1:N) —>
Edition (N:1) —>
EditionVersion (N:1) —>
type=”imf:AbstractLinkType”
type=”imf:AbstractLinkType”
type=”imf:AbstractLinkType”
type=”imf:AbstractLinkType”

46
Appendix C – The standard
Ifra Special Report 6.21.3
© 2002 Ifra, Darmstadt
EditionVersion (1:N) —>
EditionVersion (N:N) —>
EditionVersion (N:N) —>
Edition (1:N) —>
type=”imf:AbstractLinkType”
type=”imf:AbstractLinkType”
Element (N:N) —>
Element (N:N) —>
Element (N:N) —>
Element (N:N) —>
Film (N:N) —>
Film (N:N) —>
FormeBitmap (N:1) —>
type=”imf:AbstractLinkType”
type=”imf:AbstractLinkType”
FormeBitmap (N:N) —>
FormeBitmap (1:N) —>
FormeDescription (N:1) —>
FormeDescription (N:N) —>
FormeDescription (N:N) —>
type=”imf:AbstractLinkType”
Issue (N:1) —>
Issue (N:N) —>
Page (N:1) —>
type=”imf:AbstractLinkType”
type=”imf:AbstractLinkType”
type=”imf:AbstractLinkType”
Page (N:N) —>
Page (N:N) —>
Page (N:N) —>

© 2002 Ifra, Darmstadt
Ifra Special Report 6.21.3
Appendix C – The standard
47
Plate (1:N) —>
Plate (N:N) —>
Plate (N:N) —>
Position (N:N) —>
PrintingJob (1:N) —>
PrintingJob (N:N) —>
PrintingJob (N:N) —>
Product (N:1) —>
Product (N:N) —>
Product (N:N) —>
Product (N:N) —>
Reel (N:N) —>
Route (N:1) —>
Route (N:N) —>
Route (1:N) —>
Bundle (1:N) —>
Element (1:N) —>
type=”imf:AbstractLinkType”
type=”imf:AbstractLinkType”
type=”imf:AbstractLinkType”
type=”imf:AbstractLinkType”
type=”imf:AbstractLinkType”
type=”imf:AbstractLinkType”
type=”imf:AbstractLinkType”
type=”imf:AbstractLinkType”
type=”imf:AbstractLinkType”
type=”imf:AbstractLinkType”
type=”imf:AbstractLinkType”
Position (1:N) —>
Position (N:N) —>
Element (N:N) —>

48
Appendix C – The standard
Ifra Special Report 6.21.3
© 2002 Ifra, Darmstadt
Van (N:1) —>
type=”imf:AbstractLinkType”
type=”imf:AbstractLinkType”

© 2002 Ifra, Darmstadt
Ifra Special Report 6.21.3
Appendix D – Extending the standard IMF schema
49
Appendix D – Extending the standard IMF schema
To add activities, attributes and new object classes, a
local schema definition describing the additions must be
defined.
Below is an example of a local extension schema.
Adding an object class
A new object class is defined by adding a single line in
the extension schema. The example below defines a resource
class called “PrintingPress”.
Adding an activity
A new activity “Printing” is defined with the following
line in the extension schema
Adding an attribute
A new attribute “SpecialWaste” is defined with the following
line in the extension schema.
Extending an attribute value set
Extending the set of allowed values for an enumeration
attribute is not possible. Instead the attribute must be
redefined in the extension schema.

50
Appendix E – Examples
Ifra Special Report 6.21.3
© 2002 Ifra, Darmstadt
Appendix E – Examples
The best way to understand IfraTrack is by looking at
examples. This section shows a number of example messages
together with short explanations. It also discusses a
simple way to implement IfraTrack support.
Note that most examples use unique ids as the object
path. This could just as well be a complete link path identifying
all objects from the issue class down to the object,
but the UID takes less space.
The examples expect a local extension to the basic
IfraTrack schema. The extension adds a name space
“demo” and should at least define the activities “Page-
MakeUp”, “Ripping” and “PlateMaking”, along with the resource
classes “Producer” and “RIP”.
Example 1 – Page planning
This is an example on how to specify a deadline and a
planned resource allocation in an IMF message.
This is done by specifying a deadline element and a
planned resources element in the message. The resource is
identified in an object path by specifying the resource object
class (Producer) and the name attribute value (Mr
Smith). The message above specifies that the page should
be completed by “19:30” and the producer “Mr Smith” is
planned for the job.
3.0
2000-10-06T14:32:14+02:00
200010070314
completed
2000-10-06T19:30:00+02:00
late
completed
Mr Smith

© 2002 Ifra, Darmstadt
Ifra Special Report 6.21.3
Appendix E – Examples
51
Example 2 – Page make-up
When temporarily closing a page document in a page
make-up application such Quark XPress, a message could
be generated to indicate that the page is currently not in
use. This could be done by letting a plug-in module (an
XTension in the Quark XPress case) sending a message
whenever a document is closed. The message below also
specifies who closed the document.
3.0
2000-10-06T19:30:00+02:00
200010070314
on_hold
Mr Smith

52
Appendix E – Examples
Ifra Special Report 6.21.3
© 2002 Ifra, Darmstadt
Example 3 – Page output
When starting to RIP the black separation of a page a
RIP supporting IfraTrack might send the following message:
3.0
2000-10-06T19:30:00+02:00
200010070314:black
in_progress
PIP 1
Systems not aware of the complete product structure
need some information about the object that is being
processed. In the RIP case, this information could be provided
as a PostScript comment within the PostScript file.
The PostScript comment causing the above message to be
generated could look like this:
%IfraTrack-uid: 200010070314

© 2002 Ifra, Darmstadt
Ifra Special Report 6.21.3
Appendix E – Examples
53
Example 4 – Plate-making
A plate-scanner system supporting IfraTrack could
send a message like the one below whenever a plate is
scanned. The unique id information could be provided by
adding a bar code on the film.
3.0
2000-10-06T19:38:14+02:00
20001007031401
completed

54
Appendix E – Examples
Ifra Special Report 6.21.3
© 2002 Ifra, Darmstadt
Example 5 – Printing
During the printing process a press control system or a
copy counting system might want to send information
about the progress of a printing job. This could be done by
continuously sending attribute updates as follows:
3.0
2000-10-06T00:11:00+02:00
2000100703
14322
2955
0

© 2002 Ifra, Darmstadt
Ifra Special Report 6.21.3
Appendix E – Examples
55
Example 6 – Using object paths
Below are a number of messages describing how objects
are created and linked to each other by using unique
identifiers and object paths.
Let us say that a page assembly system creates a new
page, which means in terms of IfraTrack, a new element of
type “complete page” has been created. At this stage, the
page has not been assigned to any particular physical page
on a product. Therefore the only way to identify the element
for now is to use the unique name used within the
page assembly system. The following IMF message would
be sent:
3.0
2000-10-06T08:22:11+02:00
542222139
World News 1
complete_page
in_progress

56
Appendix E – Examples
Ifra Special Report 6.21.3
© 2002 Ifra, Darmstadt
At a later stage, it is decided to place this element in
two different edition versions. An IMF message will be
generated by the system used to make this link:
3.0
2000-10-06T10:15:28+02:00
542222139
2000-10-07
City
First
Main
6

© 2002 Ifra, Darmstadt
Ifra Special Report 6.21.3
Appendix E – Examples
57
2000-10-07
Country
First
Main
4
Now it is possible for any system to refer to this element
in three ways as outlined below:
3.0
2000-10-06T12:35:46+02:00
542222139
on_hold

58
Appendix E – Examples
Ifra Special Report 6.21.3
© 2002 Ifra, Darmstadt
3.0
2000-10-06T12:35:46+02:00
2000-10-07
City
First
Main
6
World News 1
on_hold

© 2002 Ifra, Darmstadt
Ifra Special Report 6.21.3
Appendix E – Examples
59
3.0
2000-10-06T12:35:46+02:00
2000-10-07
Country
First
Main
4
World News 1
on_hold

60
Appendix E – Examples
Ifra Special Report 6.21.3
© 2002 Ifra, Darmstadt
Generating IFRAtrack messages –
a template approach
An easy and flexible way to implement simple
IFRAtrack support is by using template files. Often the IMF
messages a system is sending are static, except for a few
“variables”. Let us look at the example with the RIP (example
3). Most of the message is static. What differ between
different messages are the time stamp, the unique ID, the
state value and perhaps the application field. By using the
template file below, the only thing that needs to be done
when generating a message is to replace the variables
(%unitid, %time, %uid, %state) with real values. Make sure
that the variables are coded in a way so that they cannot
be part of the real message.
3.0
%time
%uid
%state
%unitid
Object identification
When collecting information from a number of different
local systems, for example when implementing a global
production management system, it is not likely that all
systems refer to an object in the same way. There is always
a need for some kind of naming convention – rules about
how to refer to different objects.
Most likely all systems will not be able to use the same
naming convention. An IMF collecting system will need a
configurable UID translator module, to be able to handle
different naming conventions. Such a module will also improve
the flexibility of the system. If a local system is replaced
with a new system that do not refer to objects exactly
in the same way as the old system did, this could be
solved by simply reconfiguring the translator module.

© 2002 Ifra, Darmstadt
Ifra Special Report 6.21.3
Appendix F – CIP4 and JDF
61
Appendix F – CIP4 and JDF
The following paragraph is taken to a great extend
from the CIP4 website www.cip4.org and Ifra wants to
thank CIP4 for the permission to use the text as information
for the Ifra members.
The version 3.0 of IfraTrack is based on two emerging
technologies, XML and JDF. It just turned out that XML is
becoming the new standard for document layout and enrichment
with additional information, e.g. for archiving or
history data. The JDF (Job Description Format) is based on
XML Schema, which allows much more data typing for
data communication than a normal DTD (Document Type
Definition).
What is the driving force for these developments?
The need for a comprehensive system integration in
the graphic arts industry:
Printers are generally confronted with the following
trends in the graphical arts industry:
> shorter runlength of jobs,
> more complex jobs,
As fully automated workflow is required to make
processes more productive, more flexible and more transparent.
Despite the great advances made in the industry in
the last century, some difficulties in the graphic arts production
process have thus far proved insurmountable.
In the beginning, all was manual. Then came mechanisation,
which paved the way for automation. Automation
permitted press operators to dictate in advance how each
separate machine would function.
Eventually, production controllers assembled systems
involving machines with multiple capabilities run with
modular automation, all controlled from a centralised console.
The devices themselves were not connected, nor was
the process a fluid one, but the possibilities were becoming
clearer. Each advance spawned another opportunity for
greater growth. Once automation was in place, a job ticket
format was the next logical step.
No technological advance before the development of
JDF had yet provided the printing industry with the ability
to counteract the “islands-in-a-stream” problem. In other
words, although production facilities can attend to each
individual element of a print job and can even link some
of those processes, they are incapable of automating a system
to run a job from the moment a customer places the
order to the moment the final product emerges.
A significant reason that this continues to be a problem
is that multi-vendor cooperation is still possible only
on a very limited basis. It still takes significant effort to get
machines manufactured by different companies to work
together. The encoding capabilities of versatile languages
such as XML have been recognized, but, so far, not fully
exploited.
Furthermore two of the biggest and most important islands
in the printing stream are the ones that progress so
far had the least success in connecting. Management Information
Systems (MIS), generally responsible for the
planning and controlling of a job, and production services,
responsible for the operation of a job still toil in relative
isolation from the communication standpoint. In other
words, there is no means for consistent, automatic, and effective
bi-directional communication between the two indispensable
facets of every printing business. All data enumerating
planning and scheduling, process results, job status
and job tracking must travel from production to MIS so
that the latter can process the information and provide instructions
on how to continue. This continues to be a manual
procedure.
In short, what exists is an entire process that is comprised
of multiple machines and functions, all necessary
for the completion of a job, but incapable of working as a
coherent unit. Most industries would find this kind of fragmentation
unthinkable in today’s age of digital unification
because it is inefficient, which is a cardinal sin in the business
world.
JDF provides not only a solution, but a flexible and
comprehensive one. It is capable of creating a bridge between
each separate island in the printing stream, from the
moment a customer places an order to the moment the finished
product is placed in the customer’s hands, regardless
of how many manufacturers contributed machinery to the
apparatus, or how complex the task. It can also link the
two separate strata essential to the completion of each
print job: MIS and production.
What is JDF?
JDF is a comprehensive XML-based file format and
proposed industry standard for end-to-end job ticket specifications
combined with a message description standard
and message interchange protocol.
JDF is designed to streamline information exchange
between different applications and systems.
JDF is intended to enable the entire industry, including
media, design, graphic arts, demand and e-commerce companies
to implement and work with individual workflow
solutions.
JDF will allow integration of heterogeneous products
from diverse vendors to seamless workflow solutions.
Likewise, to develop an open, extensible, XML-based
job ticket standard, as well as mechanism that provides
new business opportunities for all individuals and companies
involved in the process of creating, managing and
producing published documents in the new economy.
Building on existing technologies of CIP3’s PPF (Print Production
Format) and Adobe’s PJTF (Portable Job Ticket
Format), the Job Definition Format supplies a means for
printing businesses to streamline the process of producing
printed material.

62
Appendix F – CIP4 and JDF
Ifra Special Report 6.21.3
© 2002 Ifra, Darmstadt
The most prominent features of JDF are:
Ability to carry a print job from genesis through completion.
This includes a detailed description of the creative,
prepress, press, postpress and delivery processes.
Ability to bridge the communication gap between production
and Management Information Services. This ability
enables instantaneous job and device tracking as well as
detailed pre- and post calculation of jobs in the graphic
arts.
Ability to bridge the gap between the customer’s view
of product and the manufacturing process by defining a
process independent product view as well as a process dependent
production view of a print job.
Ability to define and track any user defined workflow
without constraints on the supported workflow models.
This includes serial, parallel, overlapping and iterative processing
in arbitrary combinations and over distributed locations.
JDF is not an application or product that you can purchase
but is a data format. The new Job Definition Format
will play a significant role in future fully automated workflow
solutions yet and will be the basis of such systems
which have to be developed by the vendors.
JDF is compatible to the PPF (Print Production Format)
and PJTF (Portable Job Ticket Format) by Adobe and it
also supports jobtracking functionality of IfraTrack.
JDF provides a flexible adjustment to almost every
customer workflow.
The reason for this capability is that JDF has got a very
powerful internal tree-like structure of information and
that JDF is encoded in XML, a standard controlled by the
World-Wide Web Consortium (W3C).
JDF is highly extensible with respect to future requirements.
Features of XML have been chosen to allow easy
extension of the specification to support processes and devices
not anticipated in version 1.0 of the specification.
JDF supports a continuous production control.
Branching and Merging of partial orders facilitate an
automated production workflow at multiple sites and a cooperation
of different partners like printers as prepress
service providers.
Preset Values may be generated or entered by Management
Information Systems or by prepress devices and be
routed to subsequent production systems. This allow to reduce
setup times of expensive press and finishing equipment
significantly.
JDF also supports colormanagement for high quality
printing demands.
Eventually future Management Information Systems
will benefit from JDF’s scheduling and production planning
capabilities.
JDF facilitates job costing and job monitoring for a
full transparency of production.
Both, planned and actual production times and operating
data are reported to the Management Information System
for job costing purposes.
JDF will let you also know what material has been
consumed or used by the various production steps.
Eventually the Job Messaging Format (JMF) will help
to monitor the complete workflow and to track all jobs in
real time. It supports the exchange of dynamic data like
device related information, status & progress messages and
queue management.
JDF supports quoting and ordering of jobs via internet
based solutions and e-Business applications.
An abstract modelling of product intents is supported
in order to allow print/buy submitting requests for quotes
via a dialogue on a web page.
Fuzzy customer requirements can also be submitted
which may describe range of possible values for certain
production-relevant parameters.
Of course JDF does also contain the required customer
data and information about the destination of the product
delivery.
JDF is a vendor-independent standard.
JDF shall become a vendor-independent and widely
adopted industry standard. While the first version of JDF
was being developed by four initiating companies, it was
agreed to pass the intellectual properties rights on that
specification to the CIP4 consortium. This will ensure that
all vendors can develop systems that use JDF, and that no
vendor is disadvantaged with respect to any of his competitors.
Additionally CIP4 aims to involve even the users of future
workflow systems for definition of new and close-topractice
features of the new data format.
Who is the CIP4 consortium
CIP4 is an international, world wide operating standards
body located in Switzerland. The purpose of the association
is to encourage computer-based integration of all
processes that have to be considered in the graphic arts industry,
in particular the specification of standards.
The International Cooperation for the Integration of
Processes in Prepress, Press and Postpress (CIP4) is the successor
of CIP3 which started 1995 as a joint initiative of
vendors for the graphic arts industry. Since then CIP3 has
developed the Print Production Format which is today implemented
in many applications.
Even in the future CIP4 is going to extend its activities
and the number of different types of members. CIP4 is
about to develop and promote vendor-independent standards
for the graphic arts industry, such as the new Job
Definition Format.

© 2002 Ifra, Darmstadt
Ifra Special Report 6.21.3
Appendix F – CIP4 and JDF
63
CIP4 runs several working groups in order to develop
new extensions of JDF and to discuss future use cases. This
is supposed to be an ongoing process where different
groups are to contribute to:
Advertising/Magazine publishing
Color Workflow
Device capability description
Device messaging/Job tracking
eCommerce
Finishing
Gravure
Newspaper
Packaging & Label
Process resources and definitions
Tools & Infrastructure
Use cases/Compliance
Variable Data
Web/Rotary printing
What is Ifra expecting from this alliance?
Up to now, IfraTrack has only played an isolated role
in the Scandinavian newspaper industry. Vendor support
has been limited to a few suppliers, who have developed
solutions based on IfraTrack. With joining the CIP4 consortium
and putting IfraTrack into a broader picture including
all processes in printing and media production,
Ifra is convinced that IfraTrack will gain more and faster
acknowledgement in the industry.

Other Ifra Special Reports dealing with:
6 General topics
(as of February 2002)
6.10 ANPA/TEC ’91: Innovation despite tough times
6.11 The ISO 9000 certificate, encouragement and guarantee for a continually effective quality
control system
6.12 ANPA/TEC 1992: The newspaper industry shows cautious optimism in Atlanta
6.13 NEXPO ’93 in New Orleans: still no light in sight at the end of the tunnel
6.14.1 Introduction to the basic principles of EDIFACT
6.14.2 Newspaper advertising online
6.15 Lean Production in the newspaper industry
6.16 NEXPO ’94 in Las Vegas
6.17 Environmental audits at newspaper operations
6.18 NEXPO ’95: Satisfying the short-term needs
6.19 IfraTrack: a recommendation for the interchange of status information between local
and global tracking systems in newspaper production
6.20 Quality failure costs in newspaper production
6.21.1 IfraTrack 2.0 – Executive Summary: A specification for the interchange of status
and management information between local and global production management systems
in newspaper production
6.21.2 IfraTrack 2.0 – a specification for the interchange of status and management information
between local and global production management systems in newspaper production
6.22 The importance of legibility for modern publications
6.23 Analysis of the ad booking process
All topics of Ifra Special Reports
1 Materials 2 Pre-Press 3 Press 4 Mailroom and Distribution 5 Communication 6 General
Should you wish to receive one or several copies of these Ifra Special Reports, contact:
Ifra · Washingtonplatz · 64287 Darmstadt · Germany
Phone +49.6151.733-762 · Fax +49.6151.733-800 · http://www.ifra.com