Beyond XML and JDF: the next step

While XML and JDF form the basis of print automation, other newer formats are emerging that can make data transfer for printers even more efficient.

In our series explaining the standards and file formats that are used in the processes of print automation, we have looked at XML and the more sector-specific version of XML – JDF and the newer XJDF. However, there are other options that have either grown out of, or which offer an alternative to these formats.

The first of these is PrintTalk: a system managed by not-for-profit organisation CIP4 (the International Cooperation for the Integration of Processes in Prepress, Press and Postpress). According to CIP4, PrintTalk grew out of “a community formed by print management systems and e-commerce companies to define a ‘best practice’ common and open communications interface between companies who buy printed products, and those who manufacture them”. 

In practical terms, by supporting and extending the use of JDF, XJDF, XML and CXML, PrintTalk can add vital financial data to the management information system (MIS).

“PrintTalk is essentially a wrapper around JDF or XJDF,” CIP4 Chief Technical Officer Rainer Prosi (pictured above) explains. 

PrintTalk is the ideal standard for somebody who has a web-to-print system that creates or orders product

“But whereas JDF or XJDF is really just production information, PrintTalk has concepts like this is a request for a quote, or this is a quote, or this in an invoice, or this is a purchase order.

“PrintTalk incorporates business transactions and for business transactions, you also need to describe what the transaction is about, and that’s where the product descriptions – in this case from XJDF – come into play. It’s the ideal standard for somebody who has a web-to-print system that creates or orders product. Using PrintTalk you can describe the product that has been ordered and also put in things like what price has been negotiated. That can then be put in the job ticket and sent to an MIS to define the processing of that job.”

Give it a REST

However, variations of JDF or XJDF aren’t the only option to printers, customers and manufacturers, especially when it comes to sending information over the web. One of the downsides of JDF – and the catalyst for the creation of the more streamlined XJDF – was that almost too much data could be incorporated, making the format, at times, rather unwieldy. To counter this, there is REST API, or to give it’s full name: Representational State Transfer Application Programming Interface.

XML and JSON are conceptually very similar in that they’re structured content that allows you to define key value pairs

In simpler terms, REST APIs use the JSON format – which is broadly equivalent to XML – to create highly specified data transfer for specific jobs between compatible systems, with information being easily transmissible over http.

“XML and JSON are conceptually very similar in that they’re structured content that allows you to define key value pairs. The practical advantages of JSON in a web API environment is that there are many frameworks with ‘built-in’ JSON capability and JSON is also slightly more concise. The advantages of XML are more mature validation tools,” Rainer explains.

“Then REST API simply means sending JSON over http. APIs are easier to understand because you can make them very dedicated to your software. If you use JDF or XJDF, then you have an abstract idea of a product or a process but, if you have an API, then you can make a single entry for, for example, each button on your user interface or for each text field. 

“So you can say, this text field is precisely for this part of the API. It’s very easy for somebody using that to see how it maps to the product. But it also means if the features of the product changes, then the API has to change, too. And as it is specific, it does mean you have to write custom code for each application.”

It’s good to talk 

While APIs’ specificity is highly efficient once set up and designed for particular purposes, it does have its drawbacks.

“If manufacturers have their own APIs for their products, of course it’s not standardised, and standardisation is a two-sided coin. If you standardise, then you have to be very general because there are all kinds of use cases that you have to look into,” Rainer says.

Although APIs are specific to the job or process in hand, the similarity between XML and JSON means intercompatibility between formats is possible

“However, anybody who wants to integrate with an API is doing it just for that specific situation and they are then locked in. For example, if a printer wants to change supplier of a prepress system, and the printer is using the REST API of that prepress system, then they have to throw away everything they have done to set up their workflow and start again from scratch.” 

Although APIs are specific to the job or process in hand, the similarity between XML and JSON means intercompatibility between formats is possible, and CIP4 is working on a translation tool right now.

“It’s fairly simple to translate XML to JSON and back – there are a few caveats but generally it is fairly easy,” Rainer says.

“What CIP4 is working on is a one-to-one translation of XJDF to JSON, so that you get the best mix of both possible worlds. You can build REST APIs but they are then standardised so that you are not locked into the same equipment manufacturer. 

“Of course, manufacturers like it if they can lock in their customers; customers do not. So then come the business decisions because customers will have to go to their vendors and say they want standards and more flexibility. The question of whether the manufacturers actually support this… well, that’s the next stage in the story!”