JDF BASICS -- It's Just the Ticket

BY MARK SMITH

The devil is in the details, as the saying goes. Even simple tasks can require complex explanations in order to eliminate ambiguity and minimize the chances for confusion.

There's an exercise often used in writing classes that provides an easy, and very relatable, way for anyone to get a sense of the challenge. Using only words, try stepping another person through the process of tying a shoe. No hand gestures or demonstrations of any type are allowed. The precise directions, and not their intent, must be closely followed by the shoe tier.

With some effort, most people eventually can get a subject to tie a sloppy bow. The results certainly will not be on a par with a knot they simply tied themselves, and the instruction method takes far longer.

Now imagine trying to clearly define every aspect of print production, from job submission and preflight to packaging and shipment. Such is the task undertaken by the Job Definition Format (JDF) development effort. The most recent version of the specification and supporting documentation spans a very hefty 546 pages.

A Cure for Insomniacs?

Even those responsible for developing the spec recognize it's a tough read. Martin Bailey currently is serving as CEO of CIP4 (the International Cooperation for the Integration of Processes in Prepress, Press and Postpress), which is the standards body behind JDF. In writing about the specification, he noted that reading the "Preface & User Overview" probably would provide a sufficient grounding in JDF for any graphic arts professional not involved in programming.

Along with its length, part of what makes the specification a tough read is learning the lingo. The text is peppered with its share of acronyms. Even so, there are parts of the document beyond the "Preface & User Overview" that also deserve attention.

Using the specification's own words is probably the best way to explain what it is:

In the next few years it is our belief that this specification will positively effect everyone involved in the creation and production of printing; regardless of form (offset, digital, and so on) or function (direct mail, publication, packaging, and so on). Furthermore, JDF will be of value to companies both large and small. Some of the benefits JDF may provide include:

** A common language for describing a print job across enterprises, departments, and systems.

** A tool for verifying the accuracy and completeness of job tools.

** A systems interface language that can be used to benchmark the performance of new equipment and that can reduce the cost of custom integration.

** A basis for total workflow automation that incorporates all aspects of production—human, machine and computer (otherwise known as computer-integrated manufacturing).

** A standard that can be applied to eliminate wasteful rekeying and redundancy of information.

** A common computer language for printing and allied industries.

The bulk of the specification is concerned with defining and describing all of the production processes (called nodes) and materials that are likely to be used by the graphic arts industry as a whole. Recognizing that printing is a flexible, or custom, manufacturing environment, it doesn't try to define a standard workflow. Instead, JDF establishes standard process building blocks (defined in XML) that can be used to digitally emulate any real-world print workflow. Theoretically, it provides a mechanism for exchanging process instructions and job parameters in an open, coherent fashion.

At the core of JDF is the Job Messaging Format, or JMF. The specification describes JMF as a subset of the broader format that is designed to handle the communication of data between equipment and systems in a printing plant. Communication can occur at the central command level or directly from subsystems, such as a color control unit on a press. "JMF can be used to establish a queue, discover the capabilities of a JDF-enabled device, determine the operational status of a device, and so on," the spec notes.

The design of JMF potentially allows for direct communication between pieces of equipment that support it. However, the specification advises that—in almost all cases—a print shop will want to set up all of its production equipment to communicate with a MIS (Management Information System). "It is the MIS system that controls the scheduling, execution and management of work in progress. The role of this system is described within this standard, but it isn't highly defined," the documentation reads.

Throwing a Curve

Some of the smallest parts of the specification raise the most concern about potential barriers to its successful adoption. The "extensibility" of JDF, for example, is seen as likely being the most contentious issue, but also necessary to avoid limiting its potential and applicability. It allows for system developers and users to add their own XML elements, attributes and enumerations to a JDF application while still being in compliance.

The specification states that "CIP4 acknowledges it can't define everything, nor should it prevent innovation by codifying everything in a static manner." It does offer a strong cautionary note, however.

"If they use extensions to JDF, your technology providers should be able to provide you with a fully validated JDF schema and documentation that includes the use of their extensions. Extensions that are not documented, or that may not be disclosed to third parties for integration purposes, should be viewed skeptically," it advises.

While on the subject of customization, U.S. printers are likely to be interested in the short paragraph on units. Reflecting the European bias in its development, JDF specifies metric units of measurement be used as the default for most values. "That means you can't use alternate units instead of the defined default units. Overriding the default units defined in this table is non-standard and may lead to undefined behavior," the documentation warns.

To throw in one final acronym, JDF is said to have been designed "with the intention of providing the highest possible level of compatibility" with the PPF (Print Production Format). PPF started the industry down the road to computer-integrated manufacturing by enabling data captured in prepress to be utilized in the pressroom and bindery. The primary implementations have been using data captured by the RIP to preset ink keys on-press and passing job layouts from imposition software to the bindery for automatic setup of cutters and folders.

PPF can be thought of as providing a subset of the functionality in JDF and as a precursor to it. A new JDF-enabled system should enable the same capabilities of PPF, but doesn't necessarily replace it. Legacy systems will dictate that the two formats continue down parallel tracks for some time.

Because of the position its products occupy in the workflow, ScenicSoft Inc. had been the nexus of much of the activity related to PPF implementation. Having since been acquired by Creo Inc., the company reportedly plans to continue its development efforts with regard to PPF and JDF. "We will continue to offer support for PPF even after we add full support for JDF output to finishing equipment," says Caycee Holt, product marketing manager for Print Planning Software at Creo Inc.

The nature of CIP3-4/PPF required that the implementation be tweaked for specific types and brands of equipment, Holt notes. "We've had to send different PPF files based on the type of equipment (cutting, folding, etc.), but all vendors use the same format," she adds. "In the spirit of open standards, we hope to deliver the JDF file in a one-size-fits-all form."

The industry's experience with implementing PPF and the extensibility of JDF have cast doubt on the "plug-and-play" interoperability of the specification. Currently, no formal process exists for testing and certifying JDF specification compliance, concedes Margaret Motamed, CIP4 chief marketing officer. However, she says the organization's System Interoperability Working Group is working to create a compliance process that is expected to include certification levels and a series of interoperability test events.

"This is a high-priority task for the working group," Motamed says. "Additionally, we are building a database of products and capabilities that will help inform users about which products are expected to be interoperable."

Given that the JDF specification itself is still evolving, the timetable for its broad adoption remains very much an open question. The current documentation poses a rhetorical question that is central to the issue of the technology's adoption cycle. "Should you add JDF-enabled systems slowly with equipment replacements and upgrades, or aggressively as part of a plant reengineering process?"

Sooner or Later?

Implicit in that question is the assumption that industry companies will implement JDF. While there does seem to be a lot of momentum behind the adoption of JDF as an enabler of computer-integrated manufacturing, printers haven't had much opportunity yet to vote with their investment dollars. Therefore, the jury is still out.

Since they typically work with vendors and printers, industry consultants/analysts have a unique opportunity to view developments from both perspectives. A couple of these experts offered their takes on the question of whether JDF will be broadly adopted? And if so, when and how?

"I'm sure the industry will adopt JDF because, ultimately, it is in everybody's interest," asserts David Zwang, president of Zwang & Co. in Danbury, CT. However, he doesn't expect the implementation process to be without its challenges, especially since companies only have a specification to work with so far.

"A specification doesn't tell you how to get there," he notes. "Everybody can read and interpret it differently, yet still be within spec. There's also the issue of how printers are going to integrate JDF into the systems they already have in place. Shops have a big investment in their current workflows."

In time, Zwang says he expects vendor support to "shape up nicely," including system interoperability. Early on, however, the most progress is likely to be made by companies providing turnkey solutions, he adds.

The length of the JDF adoption cycle will depend on how much incentive the vendors are given to implement it, Zwang points out. "Since everybody is going to offer it, JDF compliance won't end up being a real value-add or product differentiator," he notes. "People are still not completely satisfied with the current state of the spec. Until they feel the pressure from a marketing standpoint, some companies will continue to wait to see the next version."

When pressed to make a prediction, Zwang says he expects to start seeing robust JDF solutions at DRUPA 2004. "But, it will take another three to five years before we get to the point where JDF adoption is ubiquitous."

JDF is the right answer, simply states K. Richard Littrell, president of Littrell Associates in Groveland, MA. "People want process automation, and JDF is the only way to get there," he explains.

Having lived through some of the industry's past attempts at interoperability, Littrell says it's not yet clear to what extent vendors will have an incentive to add special hooks to their implementations.

"I'm not sure if there will be advantages from a technical standpoint. Maybe there would be a need to extend the spec for something like Hexachrome support," he speculates. "However, vendors are going to have to cooperate for the Smart Factory concept to succeed."

The consultant also questions how many companies will be in a position to tweak their JDF implementations to make them better than somebody else's for marketing purposes. "A vendor has to have a broad enough product line for the claim to make sense," he points out.

Littrell expects printers to push the vendors to make JDF work. "My sense is that system integration will end up being part of the manufacturer's installation and setup," he says. The consultant adds that he expects it to be one to three years before the industry sees true (end-to-end) integrated solutions come to market.

A Bridge Too Far

While he believes there is huge potential in the concept of JDF, William J. Ray, Ph.D. and president of Group InfoTech in Lansing, MI, is less sanguine about the outlook for its implementation. "JDF, as currently written, is impractical because it is too complex for a version 1.0 spec, and it's too isolated from legacy systems," Ray says.

"JDF will work in one case—if you buy all of your products from a single vendor," he continues. "But the minute you add a piece of somebody else's equipment into the mix, you're going to have a high likelihood of the system not working seamlessly."

The current 500+ page document should be version 5.0, Ray asserts. "These type of tools need to start at the lowest common denominator. Step one should be a simple solution that standardizes a way to get job data into the system," he notes.

In addition, the specification defines operations and proposes processes that shouldn't be included in such a standard, points out the technology analyst. "For example, people who try to implement the Spawn/Merge capability deserve what they get," he says.

According to the spec, "Spawning is the process of extracting a subnode from a job and creating a new JDF document that contains all of the information needed to process the subnode. Merging is the process of recombining the information from a spawned job part with the original JDF job, even after both documents have evolved independently. This mechanism is intended to make it possible to submit job parts to distributed devices, other work areas, or even outside work centers."

These functions exacerbate what Ray sees as a fundamental flaw in the JDF concept. The specification is based on what he terms a "network database," since it allows for a series of transactions to occur in a networked environment without mandating that a central data store—like a relational database—be used to manage the process.

"Without a central data store, you have no hope of controlling the process," the analyst says. "The way the system ought to be set up is for data to flow from a central store to a process and back to the data store so there is never a hidden function between data stores."

Ray believes the industry as a whole should take a pause and undertake a serious analysis of what needs to be done. "The messaging format, with central data reporting, should be made the initial goal," he says. "With constraint and simplification, a spec could be written in about 10 to 50 pages that achieves interoperable systems."

That still doesn't solve what the analyst says is a more pressing issue faced by the graphic arts industry. "The true manufacturing issues happen before the press, where the vast number of components that can cause errors are concentrated," Ray explains. "We have to reorient our thinking from being printers to data processors."