|Information||Education||Business Development||Technical Resources||Members|
Basic JDF Tutorial
JDF is based in the Extensible Markup Language (XML), but not entirely. XML was selected as the underlying standard language for JDF because it is already a widely recognized language and is a standard. The application programming interfaces for programming languages such as Java, C+ and .NET all support XML directly. There are many XML tools, databases, and so on readily available on the market. For instance, XML has found a niche, and is widely used, for communicating content between back-office systems and web servers.
XML provides rules of syntax and default data types; however, XML alone is not enough. XML does not require that a document type definition or schema be defined, against which "instances" of XML can be checked or "validated." Validation is critical to many types of applications, and especially where data is going to be imported into a database (as in the databases behind your workflow and MIS systems.) JDF is based on the Worldwide Web Consortium's (W3C) XML Schema Recommendation. By using a schema, JDF allows for validation (think preflighting, but for metadata) and allows CIP4 to create user-defined data types, (e.g., "Rectangle" or "Matrix" as used in transforms, or "NamedColor").
The JDF Specification also provides specifications for file naming (e.g., URL/URI usage for hot folder exchange) and methods for packing JDF and content files together in MIME Multipart Messages. Both make use of the hypertext transmission protocol (HTTP), which also assumes TCP/IP networking. The selection of a networking protocol and method of exchange are just as important to your process automation program as is the XML component of JDF.
The JDF Specification is freely available to the public, as is the JDF schema, at www.cip4.org. The public schema covers all the requirements of our very flexible environment. In practice, you may want to create a subset of the schema that only uses the components that correspond to your workflow. This will be discussed later.
No single device (i.e., printer, press, imagesetter, etc.) is likely to implement all that the JDF specification addresses. For instance, if you are in the digital printing business, you may not care to facilitate data on hard case binding. A RIP need not facilitate JDF preflighting. A stitcher probably doesn't need to handle image rendering data. To specify exactly what individual classes of devices need to do with JDF, CIP4 members have developed Interoperability Conformance Specifications (ICS) documents that will provide the standard for individual classes of devices. ICS documents will be used as the basis for certification testing. CIP4 has signed on GATF as the first certification testing facility and others will be added in Europe and Asia. As the certification program progresses, you will see products that are marked as "JDF Certified" and this will be to a specific ICS document. The ICS documents have been published and are freely available to the public. We expect that they will become part of your buying practices.
The Three Main Functions of JDF
Conceptually JDF has three main functions. First, it provides a single common language that supports the lifecycle of a print job. This is what people mean when they refer to JDF as a "Job Ticket" language, but it is much more than that. The second function is to provide a command and control language for devices on the shop floor. This aspect of JDF is call the Job Messaging Format (JMF). JMF has been referenced as if it is a separate specification, but it is integral to JDF. JMF allows the controlling workflow system or MIS in a process-automated environment to tell devices to start and stop jobs, reorder the queue, etc. Finally, there is inherent in JDF a flexible methodology for constructing workflows and providing the command, control, and configuration of plant automation and job production. There are several improvements made to JDF 1.2, which include:
There is a fourth main function, new to JDF 1.2, of automating the handshake, which is accomplished with the new device capabilities functionality. For instance, in JDF there are five staple folds that a stitcher may use. If a new stitcher is added to your JDF workflow, the governing workflow system or MIS must know which of those five folds the new stitcher supports. Communicating the set of JDF elements and attributes supported by a device to the MIS or workflow system is creating the "handshake."
Previously, printers had to make this reconciliation or "handshake" for themselves or with the help of their vendors and/or consultants. Some groups, such as NGP or PrintCity, have constructed the handshakes between devices of participating companies so that if you buy from the companies in one of these groups, you'll have some assurance that the handshakes have been established and the devices among the partners have been pre-integrated.
Device capabilities in JDF 1.2 allows for 1.2 capable devices to be automatically queried for the details of what aspects of JDF they can and cannot manage. This is an important step towards total plug-and-play interoperability. It may take some time before there are enough JDF 1.2 products on the market for buyers to specify and rely on this automated handshake functionality.
The Role of JDF as a "Job Ticket Format"
The analog version of a job ticket may be an envelope or folder with routing information that contains instructions and specifications about a job. It may start in sales with purchase and customer information and progress through estimating, scheduling, and into production, then on to the shop floor. As each employee does their part, they sign off on work completed and the job ticket moves on. JDF does provide a digital method for accomplishing the same functions. Like an analog job ticket, it may begin with metadata about the job provided by the customer or gleaned from sales. This customer "intent" information may not be enough to drive the production process and more information must be gotten. The customer may specify "80 lbs. offset matte white," but in estimating, your staff will add a brand name, perhaps confirm availability and the actual quantity of sheets or rolls you'll need to print the job, include overage to account for inter-process spoilage, etc.
Likewise, in JDF there are two basic categories of job input data and materials: Intent and Process. Customer Intent is preserved, but process data is added as the job progresses through its life cycle until the job can (and is) processed. Therefore, to use JDF does not mean that you must collect all data about a job upfront. A JDF instance can be augmented throughout the lifecycle of a job and the data does not all have to be keyed in either. Part of the idea behind JDF is to preserve job metadata at a point of entry in order to eliminate re-keying and its inherent problems of miscommunication, redundancy, and confusion. Some of the likely sources of JDF metadata include:
Direct entry - The method of last choice is to provide direct entry for operators.
Although some companies may literally use JDF as "tickets" in that they maintain a single file for a job and keep adding to it, in most cases the "job ticket" is a virtual construct maintained in a database within the software that controls your workflow. At its heart, JDF is an exchange format for use between systems. When a workflow system wishes to drive a device on the shop floor, it need only prepare and deliver a JDF instance with the specifics for that particular step of the process.
So JDF is more than a job ticket, it is really a standard language for preserving job data throughout the lifecycle of a print job. In fact, two of its important functions is providing for the collection of both quality control (QC) data as well as audit information about each process (i.e., start time, operator/shift, errors/waste, end time, etc.) Since audit and QC data is provided electronically and directly from devices, it can be used to troubleshoot the difference between actual and estimated costs, bottlenecks in the workflow, and automatic adjustments to inter-process overage, plus it can be used to improve management's overall view of production to help them plan improvements, maximize resource allocation, and provide customers with better job information.
The Role of the MIS
The term "MIS," as used in the JDF specification, is a bit a misnomer. MIS stands for "Management Information System," a term that, in the 1960s, meant a reporting system and later, in the 1970s and 1980s, grew to incorporate accounting, billing, inventory, and other disparate management oversight functions. MIS as used in JDF covers workflow and production management systems - the business and production functions expected in a process automation project. In our industry there are a variety of sizes and types of MIS systems ranging from enterprise-wide systems that may incorporate management reporting, accounting, etc., to departmental workflow systems that may only control prepress operations.
At it most basic, these systems must be able to accept JDF input, decompose the JDF, and store the data in its internal database. They must also be able to compose JDF from its database for output. (Beware of one-way workflow systems. Eventually, systems that take in JDF but cannot output it may prove to be roadblocks to your process automation program.) This requirement implies that these systems must be able to read and validate JDF as well as write and validate JDF.
As you may recall, validation is the process of checking a JDF instance against the public JDF schema or a working subset to ensure that the rules of structure are followed. Some companies may integrate validation functions while others may use a third-party tool. It's important to know that not any off-the-shelf XML schema validation tool can be used. In the JDF specification there are certain "if-then" conditions that an off-the-shelf generic validator will not be able to validate. For instance, if one output ICC color profile is associated to an image that is incorporated into a document file that already has another output ICC color profile and those two profile don't match, the document's original output color profile takes precedence and you may have to apply a transformation to the new image. Conditions such as these are common to the graphic arts. In the JDF specification you'll see many cases where a default is established at one point if a certain value exists elsewhere in the JDF instance. JDF validators available from CIP4 (to its members), Objective Advantage, and Adobe take these "if-then" conditions into account as well as embedded systems that many vendors are building into their JDF MIS.
Your JDF MIS or workflow system must also be able to command the devices on the shop floor to act upon a job. This is one of the main objectives of process automation and computer integrated manufacturing. To provide this command and control, your JDF MIS or workflow system must understand, read, and write JMF (more on that below) and must be able to store and utilize the input and parameter requirements of each device in your workflow.
The most important requirement is that your JDF MIS or workflow system must be able to organize a JDF job. JDF uses a very "Lego-like" approach to workflow. The specification identifies approximately 80 separate processes individually to which you can associate several "resources." There approximately 160 resources specified in JDF, which are the input and output materials and parameters (metadata) that can be associated to a process. In JDF workflows, the output of one process "node" is the input to the next, hence, the singular term "resource." Once all of the required inputs for a particular job are determined to be available by a system, it can proceed. For instance, the output of a platesetter is an imaged plate and that imaged plate is the input to a press. The press cannot begin operating until the plate is imaged. Even legacy systems with no on-board computers and manual tasks can be managed this way. On a terminal or pad, the operator would communicate job specifics and instructions and taking input such as "time completed" or "operator ID."
There are several features in JDF that are optional for accommodating even the most complex workflows. For instance, JDF allows for the spawning and merging of jobs. This feature may be used where several different signatures print concurrently on different presses, or a cover is printed concurrently, and the pieces are assembled later in bindery. You can also create "combined processes" that act together with one set of inputs and outputs in a pipeline. As an example, many digital printing devices consist of a combined RIP, printer, and finishing unit, yet there is only one set of inputs and outputs. Conventional printing is actually a combined process because you may have ink, paper, cutting, color measurement, and other processes running concurrently. An ink system may use a special variant of pipelining that incorporates maximum and minimum values: when the ink well or tank hits a lower level, the inking system goes off-line until it is refilled. Refilling may be defined as hitting a certain maximum quantity. You'll want to consider these options when selecting a JDF MIS or workflow system.
Some vendors are providing options for JDF MIS and workflow systems such as middleware that can convert back and forth between JDF and legacy device controller languages. For instance, several of the major press manufacturers have been providing fairly automated presses for several years. Such middleware will be important to making your transition from proprietary process automation languages to a JDF-enabled environment. Optionally, you may want your JDF MIS or workflow system to either include or bridge to estimating, CRM, scheduling, inventory, management and customer reporting, accounting, billing, ECommerce, and ERP systems. For instance, an integrated paper inventory system may allow you to reduce inventory levels, minimize spoilage, and get closer to a just-in-time system.
Possibly the most important option to consider is your JDF MIS or workflow system's ability to handle extensions. Although the JDF specification provides a fairly exhaustive catalog of all the XML elements and attributes that you may want to associate to each process and resource, it's doubtful that the specification incorporates every conceivable possibility. You may encounter vendors who have unique functions that require extensions to the JDF specification, and you may have even developed your own internal systems for dealing with customer or market-specific data requirements and may find it useful to employ a JDF extension of your own.
Whereas a front-end system or device on the floor only needs to pass along an extension that it does not understand, a JDF MIS or workflow system must be able to understand and make use of extensions. If you add a device to your shop floor that requires a certain job parameter that is only available as a JDF extension, then your JDF MIS or workflow system can only drive that device if it can provide the required value for the extension. Otherwise, it can never know when a job is ready to proceed in the workflow. Extensions are important but should be used with caution. After you've completed this course, you will be able to determine if a vendor has a legitimate need for an extension or if they are creating synonyms for JDF elements and attributes that are already specified in order to create a proprietary hook. Your vendors should be able to provide you with documentation for extensions. CIP4 encourages both vendors and users to submit extensions for possible inclusion in the JDF specification.
The Role of the Job Messaging Format
So far we've talked about JDF MIS or workflow systems and devices on the floor. The MIS or workflow system acts as the JDF agent and it may communicate with and command a controller. The controller is an important concept in JDF. A device on the floor may have an embedded controller, the controller may be a separate physical device, or the controller may actually control more than one device. We have even seen a couple of "departmental" controllers enter the market that deal with all the devices in a department (i.e., postpress).
The language used to communicate between JDF agents and controllers is the Job Messaging Format (JMF). JMF is part of the JDF specification. JMF also is built in XML and is part of the JDF schema. JMF allows a controller to communicate to a JDF MIS or workflow system information such as events (start, stop, error), status (available, offline, stalled, etc.), results (count, waste, etc.) and other details such as who the current operator is.
A controller may also "register" with a JDF MIS or workflow system to let the system know it is available. Where a controller controls multiple devices, it can provide registration information for the devices it supports. Note: This is information like make and model and is not a substitute for device capabilities as described above.
An MIS or workflow system may use JMF to command devices on the shop floor and may even be able to change the order of jobs in the queue. You may have noticed the heavy use of the word "may," in specification there are options and various levels of support a controller may provide for JMF. JMF messages may also be unidirectional (the MIS system provides the commands, but the controller does not respond) or bidirectional. Determining what JMF options will be required of your process automation strategy is an important part of creating an effective JDF equipment buying policy.
JMF can also be used by one controller to provide commands to another controller. This is an important feature for supporting combined processes and pipelining as described above.
Strategies for implementing JDF
The first step toward process automation and JDF implementation is to make someone responsible for developing a strategy and overseeing implementation; however, one person isn't going to be able to do it. You should also be sure that your JDF implementation project leader has the support of senior management and the availability of departmental heads and key employees in the planning and implementation program. You should also involve select customer representatives and vendors in your team.
Regarding vendors, you will want to learn what your current vendor's JDF implementation plans are. What products that you already own include JDF-enabled upgrades? Will those upgrades be automatic or are they purchased options? What about extensions?
Document your current environment and compare your vendor's upgrade path to equipment and systems on the shop floor. Are there any holes? Do your potential vendors have timely JDF implementation plans or will their products be unsupported in the future? Do you have custom-built systems that may require JDF functionality? Or do you need middleware to communicate between some legacy devices and your JDF systems? Do any of your vendors provide such middleware?
Enterprise-wide JDF implementation is probably not achievable in the short-term and you're likely to need to figure out how to phase JDF into your operations over the course of a couple of years. The key to success is capturing a return on your investment as soon as possible. Every company will have different priorities and different situations. Consider what customer niches or production lines, or departments, or plants (for the big companies) are due for capital replacement or are in the greatest need for improvement. Also consider your company's objectives and where it is most likely to realize a short-term return. By focusing on a quick return from a limited implementation, you will benefit from the experience and learn to maximize your return as you approach enterprise-wide implementation.
Profectus did a study in 2002 of the potential benefits of implementing process automation and found that a printer in North America making $10,000,0000 annually could realize positive benefits of $1.2 to $5 million dollars over a five-year period. Those savings may include:
Identified priorities and overall impact will vary from company to company. Certainly, some companies have implemented a degree of process automation with proprietary systems. In the short term, less will be gained in those areas. However, in the long term, maintenance and support for proprietary systems will become a burden compared to maintenance and support for JDF-enabled systems. This is one of the universal advantages of having a common language for all devices in our industry. This situation is similar to the move to CTP. If you were already accepting digital files from customers and outputting imposed film, the move was easy and the gains relatively marginal compared to companies that were still using process cameras and stripping film. Those other companies had much farther to go and more to gain from the change.
Once you've established your priorities and objectives for your return on investment, don't forget to establish how you will measure and evaluate success. Finally, as you go through this course, consider the options in JDF, take notes, and prepare a purchasing policy and benchmarking criteria that you can apply to JDF purchases. Buy smart!
Where to find JDF-enabled Tools, Applications, and Resources
There are several free and publicly available resources that can be found at www.cip4.org, including a CheckJDF application and a JDF Editor as well the specification and schema. Anticipating that users will need more information on products and services, a "JDF Marketplace" is being published as a quarterly PDF available for your download. The JDF Marketplace includes information on products of all types, as well as information on development tools, consulting services, and educational programs and training.
You can also sign-up at www.cip4.org for a free JDF Bulletin: an informational Email newsletter that includes updates on changes and developments, product announcements, case-studies, and articles written by members of CIP4.
CIP4 membership for users (printers, publishers, buyers, consultants, and prepress services) is only $150 per year per company. All of your staff can gain access to member-only material, including access to Email forums and working groups, sample code, an archive of documents and Email messages, and the JDF programmers API (for you do-it-yourself types). The forums provide a great resource for answers to technical questions.
If you are planning on attending major industry events such as drupa, Graph Expo, or Print, see if CIP4 is staging a "JDF Pavilion" or "JDF Parc" program. At these programs CIP4 members provide attendees with live demonstrations of JDF in action, including cross-vendor integration and interoperability demonstrations. These events usually include education presentations, information kiosks, and more.
Don't forget to ask your vendors (including your distributors) about technical support and training they may be able to provide. Several vendors are providing seminars around the globe on JDF topics. There is a 13-session JDF Expert Certificate program offered by CIP4 through the International Prepress Association that is available via the Internet on demand. (See www.ipa.org/jdf/ for more details.) Also, the Graphic Arts Technical Foundation (www.gain.org) and the Fraunhofer Institute for Computer Graphics Research (contact Stefan Daun at email@example.com) have various JDF programs or studies and may be able to provide additional support.