XJDF v JDF – My thoughts after the CIP4 Interop

Twice a year something magical happens in the print industry. The key suppliers, normally in direct competition with each other, come together and work collaboratively, for a shared purpose. This unusual event is the CIP4 Interop and it’s a place where hardware and software vendors can be found working side by side, integrating with each other’s systems, no matter how big a competitor they are in the outside world. It’s a fantastic thing to be part of.

I’ve had the pleasure of attending several of these events including the most recent one in Cambridge last month, hosted by our good friends (on the day 😊) Imprint Business Systems

One of the key topics was on the new protocol XJDF and how it differs from JDF.

What is XJDF?

We all know that JDF had some issues and there were more than a few complaints about how hard it was to work with. Its biggest flaw was that there were multiple ways of describing things, and no set place it needed to be described. It didn’t matter what order you created the job ticket and so programs receiving it had to search for the correct attributes. It made it much more difficult than it had to be.

Many of us did make it work though and, despite the disadvantages of its flexibility, we created mature JDF interfaces that do work. But many others could not and, against a tide of negative opinion from people saying that it just didn’t work, CIP4 came to the conclusion that the JDF wave had finally reached the beach.

And so they built and launched the XJDF ship as a way for the industry to continue its integration journey.

Why is XJDF so different?

The X in XJDF refers to XML. JDF 1.x, whilst it appears to be standard XML, has some features that make it incompatible with standard XML development tools. XJDF has moved away from this non-standard XML structure in order to make the JDF standard more accessible to developers who work with XML and not reliant on specific JDF tools. Plus, XJDF is a much simpler version of JDF and has been able to remove duplicate methods of describing certain aspects of a print job and remove any ambiguity in how to describe a product or products. It is in essence a culmination of industry feedback and experience from those vendors who adopted JDF 1.x. With XJDF there is absolutely only one way to create a job ticket. And everything has its place; the way you order things does now matter.

Another major difference is that JDF couldn’t support product ganging because it was too complicated – it was aimed at one job for one product. But XJDF can handle many products in one job. A major development.

Whilst everyone agrees that the new protocol is much cleaner and simpler, it doesn’t necessarily mean that the industry will adopt it. A lot of time and resource has already been spent on creating JDF interfaces, and in these difficult and challenging commercial times, it will be a challenge for vendors to commit even more.

But will the industry adopt XJDF?

The reality is that most of the leading vendors will adopt it. But I suspect that some won’t bother and will instead rely on JDF-to-XJDF translation tools. I saw this working at the Interop and on the surface it might seem like a good idea, but I worry that it might actually just provide a way for vendors to cut corners and claim to have XJDF interfaces when actually it will just be converted JDF. You may remember that this is exactly what happened with Postscript; when PDF was first introduced a lot of systems had Postscript-to-PDF converters until eventually people created their own native PDF interfaces.

So why is this a problem? Well, having any layer of conversion or transition brings a risk. Some of you may also remember the days when people used to use Microsoft Word to create html using the ‘save as html’ function. The resulting websites contained a lot of noise and performed unpredictably.

The bottom line is that you won’t get the true benefits of a cleaner, simpler schema if you’re first creating it in the noisier, more complicated JDF and then converting it. You’ll actually just be adding more noise.

Will Tharstern adopt it?

Yes, absolutely. As a believer from the very beginning, we will most definitely be adopting it. We’re not afraid to be part of that group of pioneers that set off in that first fleet of ships, nor to ride out the first turbulent waves of XJDF, like we did with its predecessor. Anchors aweigh!