|
XML-based IFRAtrack
the glue for integration in business-wide
media workflow management systems
|
 |
 |  | Find |
|
Abstract
|
Content management and production processes in the media industry are
becoming more complex, time-critical and integrated. In a bit world this puts
new demands on management and creates new possibilities of intersystem integration.
The necessary IT infrastructure is available today, but the mechanisms for
interchange of management information are not standardized.
This paper presents the new XML-based IFRAtrack recommendation, a tracking
information interchange mechanism for integrating production management systems
in the media industry. IFRAtrack was developed jointly by representatives
of newspapers, system manufacturers and research organizations.
|
Keywords
|
|
Contents
|
Introduction and background
Media production in the eWorld
The graphic arts industry – starting with the premedia operations
at e.g. newspapers, magazines, ad agencies and catalogue producers –
has undergone a radical change during the last 10 to 15 years. The Media,
IT and communication industries have radically grown closer which drives changes
for digitalisation and a richer mix of media types. For example in catalogue
production there is a need for one hundred per cent control over the editing
work – all the time! [Ifra 1999]
The former handicraft work and physical material flow managed by typesetters,
lithographers and repro houses is more or less completely implemented in the
software used by designers, photographers, journalists and other creators
today. The standardised software is in larger operations, often one piece
in the networked heterogeneous systems that form the infrastructure of the
operations.
The transition towards a completely digital premedia production in networked
environments means that physical location is less important. The creative
work as well as the more traditional production – plate making, printing
and postpress operations is often carried out by many different organisations.
The present condition means reduced lead times, more space for creativity
and improved productivity, but also a need for new organisational models and
new approaches with respect to an efficient workflow and quality assurance
of the digital production processes. The production of today is more or less
invisible and even more time critical. The many systems used within the invisible
premedia production process and a time critical operation implies that there
is a large need for production management solutions on a business wide level.
Management system concepts
In the industry in general, new approaches and concepts in the area
of management systems are seen. Improved performance, openness and standardisation
regarding hardware and software, e.g. operative systems, network protocols
and databases mean new possibilities to design and implement management systems.
Examples of management system concepts where often former system islands are
bridged are CRM, ERP and the production system itself.
The system environment in a business can be designed using the “best-of-breed”
solution. This means that the most suitable systems with respect to a specific
operation and customer need are chosen. The different systems used, often
from different vendors, are integrated in order to automate information exchange
and improve the efficiency of the business.
In 1994, the international technical newspaper organisation Ifra decided
to develop a common platform in order to support standardised intersystem
communication and a modern management system approach. The resulting recommendation,
IFRAtrack, supports standardised information exchange between systems used
in newspaper production and distribution [Fällström 1997].
The Ifra initiative does not aim at creating a restrictive standard [Enlund et al 1994]. Instead, a structured and open method for
exchanging tracking information has been developed.
Other parts of the graphic arts industry have taken different approaches
to standardisation and intersystem communication. The CIP3-consortium consists
of suppliers to the printing industry. The PPF, Print Production Format developed
by CIP3, is a digital job ticket that is aimed to reduce lead times and improve
quality in the area of machine pre-setting [Daun et al 1998].
Today, IFRAtrack is used in practice at several installations, some
since 1995. Most of them are located in the Nordic countries which have been
early adopters in the area of newspaper technology and highly automated newspaper
production. Although the IFRAtrack-recommendation is well-documented and tested,
there are still many suppliers and newspapers that do not use IFRAtrack.
Previous
Table of Contents
IFRAtrack structure
Scope and purpose
The primary objective of the IFRAtrack specification is to define a
way to exchange status and management information between local and enterprise-wide
systems. The proposed mechanism utilises the creation of enterprise-wide production
management systems that can collect the information from various local systems.
It also makes it possible to connect existing production system to an ERP-system
(e.g. SAP, Oracle or a best of breed system) through a standard information
exchange mechanism. 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.
The format has been built for flexibility and longevity. The object
structure is separate from the process model. The object states and workflow
states are also handled independently in the model. All these items are described
in the IFRAtrack 2.0 specification [Fällström 1997].
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 detail.
IFRAtrack has been developed for the newspaper industry but can easily
be implemented in magazine, catalogue and other print media production. The
focus is to handle production process data, e.g. tracking and scheduling information
that can be imported and exported to the systems that support IFRAtrack export
or/and import. IFRAtrack does not handle sales, cost and other financial data
so far.
The issue for IFRAtrack is to make the standard more accessible reduce
complexity and thereby cost reduced implementation and use. Moving from a
proprietary message platform to XML is the key for this. Then we can focus
our work on the semantics, objects and use of the standard.
Object states and workflow states
The main reason to send tracking messages is the change of object states.
By associating events with objects and their states, a tracking system can
follow the progress of production. An object can have a great number of state
values. To extend the functionality of the IFRAtrack specification, any process
state of an object can be associated with a deadline, specifying when the
process state should have reached a specific value. If the value has 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, that an object does not only contain information about
its current state, but may also contain schedule information.
Figure 1
. IFRAtrack 2.0 data model with the different object classes [Fällström 1997]
Communication method
The IFRAtrack specification 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 may be (list is not complete):
- tcp broadcast
- Object Request Brookers
IFRAtrack original message format
Developed in IMF, proprietary solution
In the beginning of the work, led by the IFRAtrack WG, there were several
discussions about the vehicle of IFRAtrack. The message format was chosen
from a vendor that supplied the grammatical and structure, this became the
proprietary IMF. 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.
Many major suppliers of management systems to the newspaper industry
support IFRAtrack [Newspaper Techniques 1999]. But, still there is a lack
of standardised IFRAtrack-parsers and tools for validation of data and error
handling of incoming IFRAtrack-messages. The present situation means that
each supplier must develop its own software to interpret and validate the
IMF-messages. A transition from IMF towards a more standardised message format
e.g. based on XML-schemas will facilitate the handling of IFRAtrack-messages
and probably lead to further increased use due to easier implementation.
New message format based on XML
Why XML for IFRAtrack
A problem with the IMF format, the messaging format in the IFRAtrack
2.0 specification, is that it is proprietary and not based on any standard.
Even though it is well documented, experience has shown that the description,
given in an EBNF-like [Thompson et al 2000]form, is difficult
for developers to understand, which is a major cause why IFRAtrack is not
more widespread than it is today.
A messaging format based on XML could solve much of this problem. Since
XML is becoming a widespread standard for exchanging various kinds of information,
and most developers have at least a rudimentary knowledge of XML, 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. To validate messages based on IMF messages,
a company is more or less required to also write a parser for the messages,
or to get someone else who already has implemented a parser to validate the
messages. This process is time-consuming and error prone. With XML, a message
supplier only needs a validating XML parser and the IFRAtrack specification
in a DTD or an XML Schema, in order to validate a message. This will greatly
reduce the probalility of misunderstandings and reduce the probability of
malformed messages causing problems in a production environment. In short,
it is easier to guarantee the quality of the messages.
The freely available high quality parsers available for XML today also
reduce the time to implement IFRAtrack receiving systems. Even though writing
a parser for the IMF format is not a monumental task, it still takes a few
weeks of implementation, bug finding and optimisation. This process can be
reduced to a few days or even a few hours, if the parser is already written
by someone else.
Why schemas
When the decision was made to base the new version of IFRAtrack on XML,
the first draft versions of XML Schemas were already available [Biron et al 2000] [Bray et al 2000] If IFRAtrack would have been based on DTDs the
conversion could have been started almost immediately, but if it should be
based on XML Schemas the work would have to be postponed until the specifications
were completed, or at least stable and feature complete. The decision fell
on schemas for a number of reasons.
The most important aspect was that schemas make it easier to extend
and adapt the model for local newspapers. In order to keep the model simple
and general, the IFRAtrack specification intentionally does not cover all
aspects of newspaper production. Instead it is allowed to make local extensions,
to fit the needs of a specific newspaper. However, with the IMF format it
is left to the newspapers and IMF suppliers how to define and provide the
extensions to the IMF readers.
With XML Schemas, this can be approached in a much more 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. It also
separates the actual tracking data (objects, attributes, status changes etc)
from the message data (timestamps, sending applications etc) in a better way
than before. This also gives new possibilities to extend the model to other
publishing environments, such as web, television or radio productions, and
even to completely different production environments. Since many newspapers
are changing focus from being newspaper producers to media- or news producers,
this can be very valuable in the future.
Finally, another important benefit of using schemas are the greatly
improved possibilities of data typing. DTDs gives very limited possibilities
of typing data, other than strings and enumerations. With Schemas, all the
data types described in the IFM specification can easily be described, and
in addition new, complex data types can be generated. This reduces the risk
of misunderstanding the specification, and gives a framework to describe the
data types in a formal syntax.
Added value to the recommendation
IFRAtrack IMF-XML work
It is important to note that changing to an XML based format instead
of IMF does not affect the model itself, only the message format. This means
that existing IFRAtrack compliant systems should not have a great difficulty
to support the new XML based format. Even a multi format support would be
reasonably feasible. In addition to the advantages for the current features
of IFRAtrack, XML will also be a great platform for future enhancements. Such
enhancements could be query support and command messages (messages requesting
for something to be performed, rather than informing when it happens).
A transition from IMF to DTD would mainly result in a new messaging
envelope. Using XML schemas as the basis for IFRAtrack the recommendation
will make it possible to develop structured customer specific additions. To
go directly from IMF to XML schema is a bigger step, since there are more
functionality that can be used. However, the result is a more flexible implementation.
There are tools for converting DTDs to Schemas but to gain full benefit from
Schemas we need to do more extensive manual work.
Conclusions
- To translate the message format from proprietary IFRAtrack-standard IMF to the world-wide accepted XML standard.
- To reduce the implementation effort by using XML, thus getting access to a large group of skilled experts.
- Standard tool components available for system supplier, e.g. parsers, modelling tools.
- Faster implementation cycle for system supplier/integrator – i.e. more cost effective for both user and supplier.
- The use of XML schema makes specialisation possible for both users and supplier.
The use of IFRAtrack in order to bridge system islands and automate
information exchange has several advantages. The supplier does not need to
develop and maintain a variety of adapters in order to exchange information
with external systems, a time consuming and non-profitable activity. The customers
get well documented and tested interfaces between the systems, which result
in reliability and modularity. Furthermore the IFRAtrack-model will replace
or at least partly replace the need for adapters in order to get a common
information exchange mechanism when using data from different suppliers in
production related data warehouse solutions. There is definitely a win-win
situation for suppliers and users in the use of a common message interchange
mechanism.
Acknowledgements
AcknowledgementsThe authors wish to thank the members of all IFRAtrack working groups.
Especially thanks to professor Nils Enlund, the father of IFRAtrack.
Bibliography
| [Ifra 1999] | Ifra, 1999 “More secure catalogue production”, article in “IFRAtrack in practice”, paper describing case studies regarding IFRAtrack use, Ifra, Darmstadt, October, 12 p. |
| [Fällström 1997] | Fällström, F. 1997 ”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, October, 21 p. |
| [Enlund et al 1994] | Enlund, N., Nordqvist, S., Alasuvanto, J. and Sulonen, R. 1994 ”An Object Model for Integrating Production Management in News papers”, Proceedings of the TAGA ’94 Conference, Rochester, NY, pp. 498–510. |
| [Daun et al 1998] | Daun, S., Lucas, G. and Schönhut, J. 1998 ”Specification of the CIP3 Print Production Format”, Version 3.0, Fraunhofer Institute for Computer Graphics, Darmstadt, May, 129 p. |
| [Newspaper Techniques 1999] | Newspaper Techniques, 1999 “IFRAtrack: a current solution for the future”, Ifra, Darmstadt, April, pp. 29-31. |
| [Thompson et al 2000] | Thompson, H.S., Beech, D., Maloney, M., Mendelsohn, N. 2000 ”XML Schema Part 1: Structures”, W3C Working Draft 25 February 2000”. http://www.w3.org/TR/xmlschema-1/ |
| [Biron et al 2000] | Biron, P.V, Malhotra, A. 2000 ”XML Schema Part 2: Datatypes” W3C Working Draft 25 February 2000. http://www.w3.org/TR/xmlschema-2/ |
| [Bray et al 2000] | Bray, T., Paoli, J., Sperberg-McQueen, C.M. 1998 ”W3C Recommendation” 10-February-1998. http://www.w3.org/TR/1998/REC-xml-19980210 |