JDF is based in the Extensible Markup Language (XML), but not entirely. XML was selected as the underlying standard language for JDF because it is already a widely recognized language and is a standard. The application programming interfaces for programming languages such as Java, C+ and .NET all support XML directly and there are many XML tools, databases, and so on readily available on the market. XML has found a niche and is widely used for communicating content between back-office systems and web servers.
XML provides rules of syntax and default data types; however, XML alone is not enough. XML does not require that a document type definition or schema be defined against which “instances” of XML can be checked or “validated.” Validation is critical to many types of applications, especially where data is going to be imported into a database (as in the databases behind your workflow and MIS systems.) JDF is based on the Worldwide Web Consortium’s (W3C) XML Schema Recommendation. By using a schema, JDF allows for validation (think preflighting, but for metadata) and allows CIP4 to create user defined data types, (ex. “Rectangle” or “Matrix” as used in transforms, or “NamedColor”)
The JDF Specification also provides specifications for file naming (e.g., URL/URI usage for hot folder exchange) and methods for packing JDF and content files together in MIME Multipart Messages. Both make use of the hypertext transmission protocol (HTTP), which also assumes TCP/IP networking. The selection of a networking protocol and method of exchange are just as important to your process automation program as is the XML component of JDF.
The JDF Specification is freely available to the public as is the JDF schema at www.cip4.org. The public schema covers all the requirements of our very flexible environment. In practice, you may want to create a subset of the schema that only uses the components that correspond to your workflow.
For the most part, vendors implement JDF in their systems; although some printers with in-house development staff have done their own development. For the most part, the printer’s role in implementing JDF is that of project manager. JDF is very flexible and does not mandate any given workflow. It is up to the printer, working with their vendors to design the workflow that best suits their needs. Almost all printers have some JDF capabilities in-house, but that does not mean that devices will automatically start talking to one another; rather, like all equipment purchases, devices in a JDF implementation must be set-up and tested.
Although automation is not new to the printing industry, what JDF does is make automation accessible to printers of all sizes. Without JDF, automation projects are very expensive custom integration projects in which all aspects of production must be considered. With JDF, a printer can begin implementing automation on a limited basis and add process and equipment at a later point … knowing that if all new equipment supports JDF, they will not have to reengineer processes that are already automated. This is why it is recommended that printers make JDF a requirement for all future equipment purchases.