This does not mean that duplicate functionality may be added into these resource types. You must make sure to
use the JDF-defined attributes and elements where possible and extend them with additional information that cannot
be described using JDF-defined constructs. For example, it is not allowed to extend the RIP resource that controls
the resolution with a foo:Resolution or foo:Res attribute that overrides the JDF defined resolution parameter (see
attribute Resolution of resource RenderingParams in Section 7.2.119).
3.11.4 Extending NMTOKEN Lists
Many resources contain attributes of type NMTOKEN and some of these have a set of predefined, suggested
enumerative values. These lists may be extended with private keywords. In order to identify private keywords, it is
strongly suggested to prefix these keywords with a namespace-like syntax, i.e., a namespace prefix separated by a
single colon (‘:’). Implementations that find an unknown NMTOKEN prefixed by a namespace prefix may then
attempt to use the default value of that attribute. For instance, if a JDF instruction contains the following text:
<TrappingParams TrapEndStyle=”HDM:FooBar” (…)/>
Based of the definition of TrappingParams, the best assumption is to use TrapEndStyle = “Miter”.
Example from TrappingParams
TrapEndStyle ? NMTOKEN Instructs the trap engine how to form the end of a trap that touches another object.
Possible values include:
Other values may be added later as a result of customer requests.
Default = Miter
3.11.5 Creating New Resources
There are certain process implementations that have functionality that cannot be specified by the predefined Resource
types. In these cases, it is necessary to create a new Resource-type element, which must be clearly specified using its
own namespace. These resource types may only be linked to custom type JDF process nodes.
3.11.6 Future JDF Extensions
In future versions, certain private extensions will become more widely used, even by different vendors. As private
extensions become more of a general rule, those extensions will be candidates for inclusion in the next version of the JDF
specification. At that time the specific extensions will have to be described and will be included into the JDF namespace.
3.11.7 Maintaining Extensions
Given the mix of vendors that will use
JDF, it is likely that there will be a
number of private extensions.
Therefore, JDF controllers must be
prepared to receive JDF files that have
extensions. These controllers can and
should ignore all extensions they don’t
understand, but under no circumstance
are they allowed to remove these
extensions when making modifications
to the JDF. If they do, it will break the
extensibility mechanism. For example,
imagine that JDF Agent A creates a JDF
and inserts private information for
Writing JDF extensions? CIP4 encourages you to become part
of the standard and submit your private extensions for review
and possible inclusion in future versions of the JDF standard.
Not only may adoption of extensions into the JDF standard
help make it easier for customers to decide to buy your
products, but CIP4 is also considering adopting a formal
review process for extensions with future editions of the JDF
standard; by participating in JDF’s development now you could
save time and customer confusion in the future.
Submit Your Extensions to CIP4