As mentioned before, each JMF endpoint defined in the context of the JDF Server will have a JDF‐to‐PD mapping file attached. At startup of the JDF server this mapping file will be loaded from disk and kept in‐memory as long as the JDF server is up and running.
When the JDF client submits a new JDF ticket (+ Data files) to the JDF server a specified mapper module will use the mapping table loaded at startup to transfer values from the JDF ticket into a default PD ticket. If all the mappings are applied correctly, the outcome should be a PD ticket containing all the ticket specifications, as if the customer had filled‐in the PD ticket directly.
General rules for the mapping process:
The module attempts to apply each mapping node in the table.
If the mapping is applied successfully it moves on to the next node
If applying the mapping fails and the mapping node is Optional="false" the mapping process stops and the entire submission attempt is considered failed.
If applying the mapping fails and the mapping node is Optional="true" it is skipped and the process continues with the next mapping node in the list.
If all the mappings or at least the ones that have Optional="false" are applied correctly, the process is considered successful and the outcome should be a customized PD ticket.
Rules for applying the different types of mapping nodes:
<jc:NumberMapping Name="Copies" Optional="false">
<jc:JdfField XPath="/jdf:JDF/jdf:ResourceLinkPool/…/@Amount"/>
</jc:NumberMapping>
The system retrieves the value at the specified XPath in the JDF ticket xml structure. In the PD ticket the Copies item gets the retrieved value.
Limitation: the retrieved value is applied in the PD ticket only if it is valid in the context of PD. For example the Copies ticket item being a number item can never be set with “John Doe” but only with a numeric value. Also the item can have constraints on the minimum and maximum acceptable value so again, if the value from the JDF is outside of these bounds, it cannot be set in the PD ticket.
<jc:DateMapping Name="Date" Optional="true">
<jc:JdfField XPath="/jdf:JDF/jdf:ResourcePool/…/@LastEnd"/>
</jc:DateMapping>
The system retrieves the value specified by the XPath. The system then tries to convert the string obtained from the JDF ticket into a valid Date object. In the PD ticket the Date item will get the serialized Date object as value.
<jc:TextMapping Prefix="" Name="FirstName" Optional="false" Separator="">
<jc:JdfField XPath="/jdf:JDF/jdf:ResourcePool/…/jdf:Person/@FirstName"/>
</jc:TextMapping>
The system retrieves the value at the specified XPath in the JDF ticket xml structure. In the PD ticket the FirstName item gets the retrieved value.
Limitation: the retrieved value is applied in the PD ticket only if it is valid in the context of PD.
For example the FirstName ticket item being a text item can have a limited length for the text. So if the text is longer than the limitation the value cannot be set.
<jc:EnumMapping Name="DocumentMediaWeight" Optional="true">
<jc:JdfField XPath="/jdf:JDF/jdf:ResourcePool/…/@Weight"/>
<jc:EnumValueMapping JdfValue="65"AccessEnumValue="65032gram047m2"/>
<jc:EnumValueMapping JdfValue="80"AccessEnumValue="80032gram047m2"/>
<jc:EnumValueMapping JdfValue="90"AccessEnumValue="90032gram047m2"/>
<jc:EnumValueMapping JdfValue="100"AccessEnumValue="100032gram047m2"/>
<jc:EnumValueMapping JdfValue="120"AccessEnumValue="120032gram047m2"/>
<jc:EnumValueMapping JdfValue="160"AccessEnumValue="160032gram047m2"/>
<jc:EnumValueMapping JdfValue="170"AccessEnumValue="170032gram047m2"/>
</jc:EnumMapping>
The system retrieves the value at the specified XPath in the JDF ticket xml structure. Next the system parses all the EnumValueMapping nodes trying to find the one with the JdfValue equal to the value taken from the JDF ticket.
If the node is found, the value of the AccessEnumValue attribute is set in the PD ticket for the ticket item specified by Name.
Example:
The value retrieved from the JDF ticket is ="100". The system will set the value of the DocumentMediaWeight ticket item to "100032gram047m2".
Limitation: the retrieved value is applied in the PD ticket only if it is valid in the context of PD. In this case the list of options defined for the choice item in PD must include the one retrieved from the JDF.
<jc:ConditionalEnumMapping Name="BindingMethod" Optional="true">
<jc:ConditionalEnumValue AccessEnumValue="SaddleStitch">
<jc:StringCondition JdfField="/jdf:JDF/jdf:ResourcePool/jdf:StitchingParams/@StitchType"ExpectedValue="Saddle"/>
<jc:StringCondition JdfField="/jdf:JDF/jdf:ResourcePool/jdf:StitchingParams/@NumberOfStitches" ExpectedValue="2"/>
</jc:ConditionalEnumValue>
<jc:ConditionalEnumValue AccessEnumValue="Staples_1">
<jc:StringCondition JdfField="/jdf:JDF/jdf:ResourcePool/jdf:StitchingParams/@NumberOfStitches" ExpectedValue="1"/>
</jc:ConditionalEnumValue>
<jc:ConditionalEnumValue AccessEnumValue="Staples_2">
<jc:StringCondition JdfField="/jdf:JDF/jdf:ResourcePool/jdf:StitchingParams/@NumberOfStitches" ExpectedValue="2"/>
</jc:ConditionalEnumValue>
....
</jc:ConditionalEnumMapping
The system parses the ConditionalEnumValue nodes. For each node it evaluates the conditions in the NumericJdfFieldCondition or StringCondition or NumericComparisonCondition sub‐nodes (see Condition evaluation below). If all the conditions in one ConditionalEnumValue node are met, the parsing stops and the system attempts to set the value of the PD ticket item with the value of the corresponding AccessEnumValue attribute.
<jc:BooleanMapping Name="Collate" Optional="true" EvaluateTo="false">
<jc:StringCondition JdfField="/jdf:JDF/…/@Collate"ExpectedValue="None"/>
<jc:StringCondition JdfField="/jdf:JDF/@Types"ContainedValue="DigitalPrinting"/>
</jc:BooleanMapping>
The system evaluates all the contained condition nodes (see Conditions evaluation). If all the conditions are met, the EvaluateTo attribute specifies what value to give to the ticket item.
In the case of the above mapping node, if both string conditions are met, the Collate ticket item will get the value “false”, otherwise the ticket item gets the value “”.
<jc:TimeSpanMapping Name="FinishingTime" Optional="true">
<jc:TimeSpan Start="/jdf:JDF/jdf:AuditPool/…/@Start"End="/jdf:JDF/jdf:AuditPool/…/@End"/>
</jc:TimeSpanMapping>
The Start and the End attributes should refer to values representing a point in time – a date and a time of day. The system will load both values and it will compute the difference in time between the two. The result will be a span of time which will be set as the value of the PD ticket item (in this case FinishingTime).
The JDF ticket can contain multiple Media definitions, for all the types of Media used to print the document.
The system first tries to identify the Media used for “Cover” or “Content” as specified by the Type attribute. For this the location specified by the MediaPartitioner node is used to analyze which pages use which Media. As a basic rule, the Media used for the page number “0” or “-1” or the page with the highest number (the last page) will be identified as the Media for “Cover”.
After the Media has been identified, the ID of the Media is used to retrieve the needed attributes from the specified location in the JDF.
Example:
MediaEnumMapping is a specialized version of the EnumMapping type.
<jc:MediaEnumMapping Name="CoverMediaColor" Type="Cover"MediaPartitioner="/jdf:JDF/jdf:ResourcePool/jdf:DigitalPrintingParams"Optional="true">
<jc:JdfField XPath="/jdf:JDF/…/jdf:Media[@ID='${MediaID}']/@MediaColorName"/>
<jc:EnumValueMapping JdfValue="White" AccessEnumValue="White"/>
<jc:EnumValueMapping JdfValue="Blue" AccessEnumValue="Blue"/>
...
<jc:EnumValueMapping JdfValue="Black" AccessEnumValue="Black"/>
</jc:MediaEnumMapping>
The system tries to identify the Media to be used for Cover (Type="Cover") by looking in the partitions node (MediaPartitioner="/jdf:JDF/…/jdf:DigitalPrintingParams"). Next the XPath in the JdfField node is updated with the ID of the chosen Media ([@ID='${MediaID}']).
Finally, the system proceeds to apply the mapping as a regular EnumMapping type.
Rules for evaluating the conditions:
String condition
Evaluating the condition is done by comparing the value retrieved from the JDF ticket at the XPath specified by JdfField to the ExpectedValue attribute.
If the node has a ContainedValue attribute instead, the condition is met if the value of the attribute is contained in the value retrieved from the JDF ticket by JdfField.
If the node does not contain an ExpectedValue or a ContainedValue attribute then the condition is met if the XPath specified by JdfField exists in the JDF ticket.
Example:
<jc:StringConditionJdfField="/jdf:JDF/jdf:ResourcePool/jdf:GluingParams/@Status"ExpectedValue="Available"/>
For the StringCondition:
IF The value in the JDF ticket at
"/jdf:JDF/jdf:ResourcePool/jdf:GluingParams/@Status" is “Available”
THEN The condition is met.
ELSE The condition is not met.
Numeric condition
<jc:NumericCondition ExpectedValue="2383.9344"JdfField="/jdf:JDF/jdf:ResourcePool/jdf:Media[@ID='${MediaID}']/@Dimension[0]"/>
The value retrieved from the JDF at the XPath specified by the JdfField attribute must be numeric. The numeric value is then compared to the ExpectedValue attribute. The condition is met if the values are equal with an accepted variation of 1.
Numeric comparison condition
<jc:NumericComparisonCondition Value_1="/jdf:JDF/jdf:ResourcePool/jdf:Media/@Dimension[0]" Value_2="/jdf:JDF/jdf:ResourcePool/jdf:Media/@Dimension[1]" Comparison="LessThan"/>
The system retrieves the numeric value indicated by the Value_1 and Value_2 attributes.
The condition is met if the numeric relation between the two values corresponds to the one specified by the Comparison attribute.
For the example above the evaluation can be read as:
IF Value_1 LessThan Value_2
THEN Condition is met
ELSE Condition is not met.