RW info

"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."

PART 1

No One's Buying JDF (for it's own sake)!

JDF products are emerging that actually work and provide real value to printers (March 2004)

One might say that JDF (Job Definition Format), the CIP4 organization's industry-wide XML standard for interoperability has been, a solution looking for a problem. The burgeoning standard, in development for a few years now, set as its ambitious goal the complete description of prepress, press and postpress processes in an XML (Extensible Markup Language) specification that now is reaching for 800 pages.

This lofty goal of "everything (i.e., software and machines) talking to everything else (i.e., presses and finishing equipment)" still hasn't quite been reached, but today, thanks to the work of almost 200 companies cooperating in CIP4 ( www.cip4.org ), and the work of many hundreds of individuals from the member companies, JDF products are emerging that actually work and provide real value to printers seeking to increase their productivity and competitive advantage.

At the recent On Demand Conference and Expo, JDF in the real world was demonstrated in a CIP4 and Advanstar (the promoters of the show) hosted "JDF Tour." Interoperability between several software and workflow vendors' applications was shown in an educational venue that was assisted by several RIT (Rochester Institute of Technology) students.

EFI, HP, Objective Advantage (a software development and consulting firm focused on JDF) and Wave Corporation (makers of the popular MediaBank Digital Asset Management system), as well as several other companies, demonstrated the ability for JDF files to be created on one system and acted upon by another.

The tour created a mock workflow for a fictitious company called "Kimono Bank". Kimono's three branches in New York, San Francisco and Miami all work with different advertising agencies and print service providers, who each employ their own workflow.

JDF provided the glue that allowed Kimono to work with these different companies, but still leverage their print assets across the corporation.

In this demonstration, JDF provided the glue that allowed Kimono to work with these different companies, but still leverage their print assets across the corporation. For example, a job submitted by a user at the San Francisco Kimono branch using EFI's exchange could be output at a print service provider on a CTP device driven by EFI's own OneFlow, or on an HP Indigo press at another print service provider. Once the job is completed, it can be stored in a web catalog application for future re-ordering by the Kimono staffers in Miami, or archived at the company's New York ad agencies in their MediaBank Digital Asset Management system.

Thanks to the JDF standard, all of this was accomplished without re-keying the job information, and without having to "import" or require the user to manually "translate" the metadata (the information about the job).

This is a simple demonstration that clearly drives home the power of JDF, and repeats of JDF tours like this are essential to help potential users fully understand its benefits. The conversations to date about JDF have been about "nuts and bolts. Now we are beginning to show real applications that drive home the importance of adopting this critically important standard.

That's the key: JDF isn't about XML and software--it's about addressing many of the challenges that the industry faces. As we approach Drupa, we're going to see a lot more applications emerging that employ JDF in really useful ways that help users, in both print buying companies and at printing companies, expand their capabilities to become more efficient and profitable by producing more work in less time with the same or less labor.

The bottom line: no one's buying JDF for its own sake! What we are buying with JDF-enabled applications is solutions to problems that can't be solved any other way.

2004 Chuck Gehman


PART 2

Drinking From A Fire Hose (by Pat Taylor, Proactive Technologies)

JDF merits our attention, but we must plan for its deployment.

May 17, 2004 -- "I couldn't go to drupa. For the first time in a long time, I have customers sending me business," said Hank. He didn't even look up from his lunch--he was as casual in response as if I asked about his weekend. "Anyway, they say it's the 'JDF drupa'."

"Well there's a lot to learn about JDF, Hank," I responded. "You'll want to know what's goin' on."

He looked me straight in the eye and locked me with his stare. "I've got a book in my office by Romano himself announcing the importance of PDF to the industry. That book is getting close to ten years old, Taylor, and we still don't have it right. Our company and our industry are more 'digital' now than ever before, and we intend to keep moving forward. But I'm going to take the time it takes to do it right. We'll study JDF, and my team will lay out a plan for its deployment. And we will execute our plan when we're ready. That sound alright to you?"

Relevant, but not Urgent

Abrupt and abrasive as he appears, Hank is usually right. I finished my meal in silence, thinking about his clear and succinct position on the subject of our limited conversation. He understands JDF as well as most people in the business--which is 'not enough'. It is a relevant technology, but it does not create a sense of urgency. It merits our attention, but we must plan for its deployment. There is a great deal of preparation required in order to move forward successfully, seize opportunities to consolidate resources, and invest in an infrastructure that will enable JDF.

JDF will describe the details of a printing job to all of the devices performing work on the job. But how will those devices communicate? Do many printing companies have a highway to support the flow of JDF information amongst compliant devices, and is the common [job] data available to the different departments of the business? Why is there a server with its own data storage system (and its own data backup system, as well) on the Business side of the business, and a second or third set of sub-systems on the Production side of the business, and why don't they share data? Is the business properly connected to communicate--within itself and with its customers? Can anyone in the business cycle access a single data pool to retrieve the information specific to their part of the operation? There is a great deal of preparation required in order to move forward successfully, seize opportunities to consolidate resources, and invest in an infrastructure that will enable JDF. (We'll talk about Comprehensive Support in a separate articleÉ)

Drink Slowly When we're ready, we will deploy JDF-capable products that make sense for our company and our customers.

"So, basically, you are telling me that you're limiting yourself to what you can do now?" Hank looked at his watch before deciding he had time to tolerate my thick-headedness.

"Listen closely, and I'll try to make it simple for you. We're consolidating our resources. We're adopting standards and building our own infrastructure. Then, when we're ready, we will deploy JDF-capable products that make sense for our company and our customers. In the meantime, it's business-as-usual."

Measured steps down a path to success. I guess there is no substitute for the wisdom that comes with experience. Hank has a plan for a big data pool, and a network that allows each department to dip into the data pool for the information it needs. A single data pool costs less, and is easier to manage and share and protect, and standards-based applications can be plugged into the system whenever and wherever appropriate. Hank is setting limits on his plans for growth and--in time--JDF will fulfill its promise.

If turned loose too soon, however, Hank and his crew could be drinking from a fire hose.