Could "JDF friendly" be a useful term?

Towards the end of the week for MAX in Chicago. It strikes me there has been no buzz about MARS, based on a search of Google News and Google blogsearch. I still think XPS is a solid project that Adobe should consider if it is Microsoft they are concerned about.

Anyway, back on topic via a trawl of Adobe blogs. Jim King explores the meaning of "XML document".

I am sure you have often heard the term “XML Document.” I hope you realized that that term is nearly meaningless just like the term “XML.” We should never use either in polite conversation. Let me tell you some of the totally different uses for the term “XML Document” which render it a useless term, and maybe you will agree with me to banish it from our vocabularies.

The point being it is better to talk about the specific XML markup language being used than XML Documents in general. "XML Document" is meaningless.

..........

If you look at the Adobe Mars literature you will find that Mars is called XML-friendly. That is my doing. I just thought it was too much of a stretch to call a ZIP archive an XML Document or an XML file.

So for most people using the word "XML" at all could be quite dangerous and result in confusion. "XML friendly" is vague enough to cause less damage. It shows a general support for the direction of XML without getting into any detail.

Something similar might help with JDF - the Job Definition Format. Again, few people understand the specification precisely. But "JDF friendly" could include any form of XML that would move into JDF without too much trouble.

In June at Adobe Live I met David van Driessche from Gradual who spoke about XMP as a way to store metadata with PDF files for print. Similar ideas come up in a Printweek story by Barney Cox including an interview with Peter Camps, also from Gradual.

What strikes me is the Barney Cox take on JDF.

JDF- that much touted tool for print production automation is also a form of metadata, but it is one that is specifically aimed at print production. JDF has been around for a while and is being adopted as a way to control print production processes, but it isn't the only metadata format around that is relevant to the print industry.

A while back JDF was also promoted as a way for print customers to define their requirement. The "intent" could be fairly simple with production methods chosen later. In another Printweek story (page 22 Oct4) Steve Vaughan points out that "Pricing on the customer's desktop has a direct effect on the way they work." So has the capability for publishers to create a print ready PDF. With JDF, customers can define detail in print production.

Once upon a time Adobe worked on the Portable Job Ticket as part of PDF. More recently they are thinking about the web and Flash. There has been almost no promotion for the feature in Acrobat 7 and Acrobat 8 that a JDF file can be created from the desktop within InDesign or Acrobat. There could be a majority of Acrobat desktops in legal or engineering sites where the pre-press features are a complete mystery. In many cases JDF would be of no interest. However it is worth pointing out to those creatives who still include print occasionally in what RIT call "the mix".

On the rare occasions when something is said about JDF, such as by Jutta Koch a couple of years ago at the LCC Futures Conference, it appears that the InDesign / Acrobat workflow could involve JDF files from pre-press to define how creatives produce files for later processing. Quark Job Jackets could work in a similar way. But this whole area seems to have gone quiet recently. Not much of a mention in the Printweek workflow technology report.

So it seems the advocates of a gradual approach have got a point. Until the print customers get together and demand JDF, as the magazine publishers did with PDF by the way, the interim aim could be something that is "JDF friendly".