XJDF Design Criteria

This update of JDF is the first major version update. Whereas the minor revisions were at least nominally backwards compatible, XJDF is a major redesign that takes a decade of experience into account.

The major conceptual change is that XJDF no longer attempts to model the entire job as one large “job ticket” but rather specifies an interchange format between 2 applications that are assumed to have an internal data model that is not necessarily based on JDF. Thus each JDF ticket specifies a single transaction between two parties. A single job may be modelled as one or more XJDF transactions.

Simplify and reduce variations

JDF 1.x allowed shorthands for some simple cases. What seemed reasonable actually made things more complex, since both shorthand and the long version had to be implemented. For instance, amount related attributes could be found either directly in a ResourceLink or in a ResourceLink/AmountPool/PartAmount. JDF 2.0 removes much of this variability.

Reduce the barrier of entry

Simple tasks should be simple to describe. In the simple (non-partitioned job metadata cases) the XJDF should be describable as a series of simple XPaths.

Replace abstract data types with explicit elements and children

Abstract elements are more concise to write, but inherited traits also tend to be overlooked by newcomers to a specification. If elements are designed to be final with sub-elements, each specification entry can be found by searching for the explicit element name.

Remove ResourceLinks

The Process / Resource model has been conceptually retained. But since there is only one node per XJDF transaction, reuse of resources is no longer an issue and ResourceLinks have been merged with their respective Resources. Thus data that belongs together is also stored in the same region of the XML.

It is still possible to specify the interactions and dependencies of individual process steps and resources or parameters using the optional ProcessList structure.Replace RefElements with exactly one of IDREF, IDREFS or inline element.

For each refElement (i.e., choice of resourceRef or inline element), exactly one choice was made. Thus the variability is reduced and implementation is simplified.

Enable dynamic changes

The monolithic model of JDF 1.x lent itself well to a plan and execute philosophy but had its limitations when changes were made after a job had been submitted. Since a Job may be modelled as a set of transactions in JDF 2.0, the idea of multiple transactions and thus also job changes is inherently built into the standard. The simplest method of initiating a change transaction is to send an XJDF that contains only the modified values. Only the explicitly stated values will then be modified.

Remove schema defaults

Since XJDF allows submission of incomplete XJDF tickets and also updates to preexisting tickets, all attributes except very few that are required for bookkeeping (e.g., @ID) have been made optional and all schema defaults have been removed.

Retain the semantic structures

A lot of work was put into the definition of individual messages, processes and resources. The detailed semantics of JMF messages and resources have been retained. Thus the detailed dictionary element and attribute names and their definitions has been retained. Thus translation between JDF 1.x and XJDF is straight forward. All deprecated traits have been removed completely.

Reduce Redundant methods

In case of redundant or conflicting definitions, one preferred method was chosen and the others deprecated, which is obviously an exception to the rule that all structures have been retained.

Align XJMF Messages and Audits

The PhaseTime and ResourceAudit have been replaced with AuditResource and AuditStatus, which have the same contents as SignalResource and SignalStatus. Thus it is now irrelevant, whether the feedback information is extracted from from a returned XJDF or from XJMF signals. The syntax is the same, although Signals re still ephemeral snapshots whereas Audit are final.

Reduce the number of Layout descriptions

StrippingParams, LayoutPreparationParams and Layout have been combined into one Layout. Note that this does not mean that the idea of high level and detailed Layout description no longer exist. They simply exist within one Layout so that additional details can be added to the high level Layout simply by using some of the detailed features, thus avoiding three methods to describe the same concepts.

Remove implementation specific details

Spawning and Merging

Since XJDF is only an interface, the specification of serializing from the internal data model and deserializing to the internal data model is outside the scope of this specification and has been removed.

Enhance Compatibility with standard XML and XML Tools

XML and XML related tools and technologies such as XPath, XSL transforms, Schema, class generators etc. have evolved and matured significantly since the turn of the century. Some of the choices in JDF 1.x, although compliant with XML have proved difficult to implement using standard tools. XJDF has been redesigned keeping the available tools in mind.

Partitioning and Inheritence

The general concept of partitioning (i.e., the notion of resource sets with multiple individual parts) is retained but the encoding has been simplified. While inheritance of elements and attributes in partitioned resources potentially can reduce redundancy of the data encoded in JDF, it also greatly increases the flexibility and variability of specifying similar data. This causes potential for reader/writer mismatch. Inheritance and the corresponding definition of cardinality (e.g., “SHALL occur somewhere in the inherited hierarchy”) is also difficult to encode as XPath or in an XML schema. XJDF therefore removes inheritance at the cost of redundant specification of traits in partitioned resources.

Capabilities and Constraints

The JDF capabilities model has been replaced with a reference to standard XML schema. This is not as powerful, but due to an abundance of schema aware commercial tools, much better alligned with mainstream XML technology and therefore much easier to implement.