Base Interoperability Conformance Specification (Base ICS) Version 1.0 Errata Revision B Date: 2006-02-19 File: ICS-Base-1.0RevB.doc
System Behavior and Interoperability WG Abstract This document is the first of a series of Interoperability Conformance Specification (ICS) documents. Each ICS defines a set of conformance requirements that a conforming JDF-enabled product must meet in order to achieve interoperability with other conforming JDF-enabled products. This document, the Base ICS, defines the conformance requirements that are common to all other ICS’s, i.e. those conformance requirements that have been factored out of the other ICS’s and placed in this ICS. This document specifies three Conformance Levels of Conformance Requirements. These levels mainly differ in the type of communication between the Manager and the Worker and include the conformance requirements for Hot Folders, string Attributes, specific JDF Elements and specific JMF Messages. The JMF Commands include: SubmitQueueEntry, ReturnQueueEntry, and StopPersistentChannel. The JMF Queries include: KnownDevices, KnownMessages, and SubmissionMethods. This version applies to interactions using JDF version 1.2.
Page 1 of 61
Base ICS, Version 1.0 Errata Revision B Copyright Notice
Copyright © 2000-2005, International Cooperation for Integration of Processes in Prepress, Press and Postpress, hereinafter referred to as CIP4. All Rights Reserved Permission is hereby granted, free of charge, to any person obtaining a copy of the Specification and associated documentation files (the “Specification”) to deal in the Specification, including without limitation the rights to use, copy, publish, distribute, and/or sublicense copies of the Specification, and to permit persons to whom the Specification is furnished to do so, subject to the following conditions. The above copyright notice and this permission notice must be included in all copies or substantial portions of the Specification. THE SPECIFICATION IS PROVIDED “AS IS”, WITHOUT WARRANTY OF ANY KIND, EXPRESS, IMPLIED, OR OTHERWISE, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT WILL CIP4 BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF, OR IN CONNECTION WITH THE SPECIFICATION OR THE USE OR OTHER DEALINGS IN THE SPECIFICATION. Except as contained in this notice or as allowed by membership in CIP4, the name of CIP4 must not be used in advertising or otherwise to promote the use or other dealings in this Specification without prior written authorization from CIP4. Licenses and Trademarks
International Cooperation for Integration of Processes in Prepress, Press and Postpress, CIP4, Job Description Format, JDF and the CIP4 logo are trademarks of CIP4. Rather than put a trademark symbol in every occurrence of other trademarked names, we state that we are using the names only in an editorial fashion, and to the benefit of the trademark owner, with no intention of infringement of the trademark.
Page 2 of 61
Base ICS, Version 1.0 Errata Revision B
Table of Contents 1
2 3
4
5
Introduction .........................................................................................................................................................6 1.1 Conformance Requirements ..........................................................................................................................6 1.1.1 Requirements that apply to any ICS ......................................................................................................6 1.1.2 Base ICS Level 1 ...................................................................................................................................6 1.1.3 Base ICS Level 2 ...................................................................................................................................7 1.1.4 Base ICS Level 3 ...................................................................................................................................7 1.1.5 Base ICS Level 0 ...................................................................................................................................7 1.1.6 Interoperability of Levels.......................................................................................................................7 1.2 JDF Instances.................................................................................................................................................7 1.3 JMF Messages ...............................................................................................................................................7 Terminology .........................................................................................................................................................8 Conformance Rules ...........................................................................................................................................10 3.1 Data Type Values ........................................................................................................................................10 3.1.1 Size Limits for Attribute Values ..........................................................................................................10 3.1.1.1 Size Limits for Simple Values .........................................................................................................10 3.1.1.2 Size Limits for Lists.........................................................................................................................11 3.1.1.3 Size Limits for Attributes with Short Strings...................................................................................11 3.1.1.4 Size Limits for Attributes Named in the PartIDKeys Attribute .......................................................13 3.2 Hot Folders ..................................................................................................................................................13 3.2.1 Requirements for Managers.................................................................................................................13 3.2.2 Requirements for Workers...................................................................................................................13 3.3 JDF Extensions and JDF 1.2 Deprecated items ...........................................................................................14 Conformance Tables – JDF Instances..............................................................................................................15 4.1 JDF Node.....................................................................................................................................................15 4.2 AuditPool.....................................................................................................................................................20 4.3 Resource ......................................................................................................................................................22 4.4 ResourceRef.................................................................................................................................................24 4.5 Device Implementation Resource ................................................................................................................25 Conformance Tables – JMF Messages.............................................................................................................25 5.1 Root Node of a JMF message ......................................................................................................................25 5.2 Conformance requirements for JMF Message Families ..............................................................................27 5.3 JMF Handshaking........................................................................................................................................29 5.3.1 Persistent Channels – Creating and Closing ........................................................................................29 5.3.2 Asynchronous Acknowledges..............................................................................................................30 5.4 Individual Message Types ...........................................................................................................................30 5.4.1 KnownDevices.....................................................................................................................................32 5.4.1.1 Query – KnownDevices...................................................................................................................32 5.4.1.2 Response – KnownDevices..............................................................................................................33 5.4.2 KnownMessages ..................................................................................................................................34 5.4.2.1 Query – KnownMessages ................................................................................................................34 5.4.2.2 Response – KnownMessages...........................................................................................................35 5.4.3 ReturnQueueEntry ...............................................................................................................................36 5.4.3.1 Command – ReturnQueueEntry.......................................................................................................36 5.4.3.2 Response – ReturnQueueEntry ........................................................................................................37 5.4.4 StopPersistentChannel .........................................................................................................................38 5.4.4.1 Command – StopPersistentChannel.................................................................................................38 5.4.4.2 Response – StopPersistentChannel ..................................................................................................39 5.4.5 SubmissionMethods.............................................................................................................................39 5.4.5.1 Query – SubmissionMethods...........................................................................................................39 5.4.5.2 Response – SubmissionMethods......................................................................................................40 5.4.6 SubmitQueueEntry...............................................................................................................................41 5.4.6.1 Command – SubmitQueueEntry ......................................................................................................41 5.4.6.2 Response – SubmitQueueEntry .......................................................................................................43 5.4.6.3 Acknowledge – SubmitQueueEntry.................................................................................................45
Page 3 of 61
Base ICS, Version 1.0 Errata Revision B 6
Conformance Tables – Job Submission ...........................................................................................................46 6.1 Complete Job Instance versus a (spawned) Process Node...........................................................................46 6.1.1 AncestorPool........................................................................................................................................46 6.2 Plain JDF versus JMF - Submit Queue Entry ..............................................................................................47 6.2.1 URL External Reference versus MIME Encoded................................................................................47 7 References...........................................................................................................................................................48 7.1 Normative References .................................................................................................................................48 7.2 Informative References................................................................................................................................48 Appendix A: How to Read ICS Documents........................................................................................................49 A.1 Overview .....................................................................................................................................................49 A.1.1 Need for Multiple ICS’s ..........................................................................................................................49 A.1.2 Avoiding Replication of Conformance Requirements .............................................................................49 A.1.3 Ramifications for Implementers ..............................................................................................................50 A.1.4 Ramifications for Vendors.......................................................................................................................50 A.2 Interfaces for Conformance Requirements ..................................................................................................50 A.3 Content of Conformance Tables ..................................................................................................................52 A.3.1 Format of Conformance Tables ...............................................................................................................53 A.3.2 Conformance Requirements for Writing and Reading.............................................................................54 A.3.2.1 Blank Cell for a Conformance Level ...................................................................................................55 A.3.2.2 Conformance Requirements for Writing..............................................................................................55 A.3.2.3 Conformance Requirements for Reading.............................................................................................57 Appendix B: Additional Supported Error Codes in JMF and Notification elements ....................................58 Appendix C: Errata Revision A, 2005-12-05......................................................................................................59 Appendix D: Errata Revision B, 2006-02-19 ......................................................................................................61
Figures Figure 1: Example of an ICS Stack .............................................................................................................................50
Tables Table 1: Minimum and Maximum Number of Characters of Specified JDF Data Types ...........................................10 Table 2: Minimum and Maximum Size of List-like JDF Data Types .........................................................................11 Table 3: Attributes with Short String...........................................................................................................................12 Table 4: Part ID Attributes – Different Size Limits.....................................................................................................13 Table 5: Worker Supported Schemes ..........................................................................................................................14 Table 6: JDF Node.......................................................................................................................................................15 Table 7: NodeInfo........................................................................................................................................................19 Table 8: StatusPool......................................................................................................................................................19 Table 9: PartStatus.......................................................................................................................................................20 Table 10: AuditPool.....................................................................................................................................................20 Table 11: Audit – Abstract ..........................................................................................................................................21 Table 12: Created.........................................................................................................................................................21 Table 13: Modified ......................................................................................................................................................21 Table 14: Resource ......................................................................................................................................................22 Table 15: ResourceLink...............................................................................................................................................23 Table 16: AmountPool.................................................................................................................................................23 Table 17: PartAmount .................................................................................................................................................24 Table 18: ResourceRef ................................................................................................................................................24 Table 19: Device..........................................................................................................................................................25 Table 20: JMF..............................................................................................................................................................25 Table 21: Message – Abstract......................................................................................................................................27 Table 22: Query – Abstract..........................................................................................................................................27 Table 23: Response – Abstract ....................................................................................................................................28 Table 24: Signal – Abstract .........................................................................................................................................28
Page 4 of 61
Base ICS, Version 1.0 Errata Revision B Table 25: Command – Abstract...................................................................................................................................29 Table 26: Acknowledge – Abstract ..........................................................................................................................29 Table 27: Message – Derived Message Families.........................................................................................................31 Table 28: Query – KnownDevices...............................................................................................................................32 Table 29: DeviceFilter .................................................................................................................................................32 Table 30: Response – KnownDevices .........................................................................................................................33 Table 31: DeviceList ...................................................................................................................................................33 Table 32: DeviceInfo ...................................................................................................................................................33 Table 33: Device – KnownDevices .............................................................................................................................34 Table 34: Query – KnownMessages............................................................................................................................34 Table 35: KnownMsgQuParams..................................................................................................................................35 Table 36: Response – KnownMessages.......................................................................................................................35 Table 37: MessageService ...........................................................................................................................................36 Table 38: Command – ReturnQueueEntry ..................................................................................................................36 Table 39: ReturnQueueEntryParams ...........................................................................................................................37 Table 40: Response – ReturnQueueEntry....................................................................................................................37 Table 41: Command – StopPersistentChannel ............................................................................................................38 Table 42: StopPersChParams ......................................................................................................................................38 Table 43: Response – StopPersistentChannel..............................................................................................................39 Table 44: Query – SubmissionMethods.......................................................................................................................39 Table 45: Response – SubmissionMethods .................................................................................................................40 Table 46: SubmissionMethods ....................................................................................................................................40 Table 47: Command – SubmitQueueEntry..................................................................................................................41 Table 48: QueueSubmissionParams ............................................................................................................................42 Table 49: QueueFilter..................................................................................................................................................42 Table 50: Response – SubmitQueueEntry ...................................................................................................................43 Table 51: QueueEntry..................................................................................................................................................44 Table 52: Queue...........................................................................................................................................................44 Table 52a: Device – Queue..........................................................................................................................................45 Table 53: QueueEntry – Queue ...................................................................................................................................45 Table 54: Acknowledge – SubmitQueueEntry ............................................................................................................45 Table 55: AncestorPool ...............................................................................................................................................46 Table 56: Ancestor.......................................................................................................................................................47 Table 57: Format of Conformance Tables ...................................................................................................................53 Table 58: Blank Cell for a Conformance Level...........................................................................................................55 Table 59: Conformance Requirements for Writing .....................................................................................................56 Table 60: Conformance Requirements for Reading ....................................................................................................57 Table 61: Additional JMF Error Codes .......................................................................................................................58 2
Page 5 of 61
Base ICS, Version 1.0 Errata Revision B
1 Introduction Because the JDF specification [JDF1.2] 1 is quite large, it is very difficult for any JDF-enabled product to implement the [JDF1.2] in full. Yet, if each JDF-enabled product were to implement an arbitrary subset of the [JDF1.2], interoperability between JDF-enabled products would be impossible. Hence, there is a need for a number of well-specified subsets of JDF, each defining an Interface between pairs of vendor’s products in the workflow. The mechanism for specifying such a subset of JDF is the Interoperability Conformance Specification (ICS). An ICS defines a subset of JDF by means of Conformance Requirements, which are a set of requirements. When a JDF-enabled product meets the Manager Conformance Requirement of a particular ICS, it achieves interoperability with other JDF-enabled products that meet the corresponding Worker Conformance Requirements of the same ICS. Note: The definitions of capitalized terms appear in section 2 Terminology below.
1.1 Conformance Requirements This document, the [Base-ICS], defines Conformance Requirements for a subset of [JDF1.2]. These Conformance Requirements are common to all Product-Sector ICS’s. This ICS specifies four Conformance Levels of Conformance Requirements. These levels differ in the type of communication between the Manager and the Worker. The paragraphs below specify the Conformance Requirements for Manager Interfaces, Worker Interfaces and Product Claims of Conformance. See Section 2 Terminology for definitions of Manager, Worker, Producer, Consumer, and JDF Instance.
1.1.1 Requirements that apply to any ICS This subsection defines the conformance requirements that apply to any ICS. A product conforming to any ICS: 1. 2. 3.
MUST produce JDF Instances and JMF Messages that conform to the [JDF1.2], MUST meet all appropriate Conformance Requirements of the respective ICS. • MUST be able to read and write XML encoded in UTF-8 (variable number of octet Unicode characters).
Any claim of conformance to any ICS by a product’s Vendor MUST follow the requirements in the “CIP4 Guidelines: For CIP4 and JDF Logo Use” [JDF-logo] for ICS conformance. The next subsections specify conformance requirements that are specific to the indicated conformance level of this Base ICS:
1.1.2 Base ICS Level 1 To be conformant to Level 1, a Manager MUST: • • •
Be able to generate a conformant JDF Instance File, Be able to submit this JDF Instance File to the worker via a Hot Folder, and Be able to receive a JDF Instance File returned by the worker via a Hot Folder.
To be conformant to Level 1, a Worker MUST: • •
Be able to accept a conformant JDF Instance File via a Hot Folder and Be able (after completion of the job) to return or forward the JDF Instance File, with specified updates, to a Hot Folder.
1
The bracketed [JDF1.2] serves as a reference to Section 7.1 Normative References. It can also be the document’s name, as in “The [JDF1.2] …”, which means “The JDF Specification, version 1.2 …”
Page 6 of 61
Base ICS, Version 1.0 Errata Revision B 1.1.3 Base ICS Level 2 To be conformant to Level 2, a Manager MUST: • •
Conform to Level 1 of this ICS and Be able to accept conformant JMF Signals via HTTP.
To be conformant to Level 2, a Worker MUST: • • •
Conform to Level 1 of this ICS, Be able to receive conformant Subscriptions in the JDF, and Be able to send out conformant JMF Signals via HTTP.
1.1.4 Base ICS Level 3 To be conformant to Level 3, a Manager MUST: • • • • •
Conform to Level 2 of this ICS, Be able to send conformant JMF SubmitQueueEntry Command Messages to a Worker via HTTP, Be able to receive and respond to conformant JMF ReturnQueueEntry Command Messages via HTTP, Be able to receive and respond to conformant JMF KnownDevices and KnownMessages Query Messages via HTTP, and Be able to receive the JDF Instance returned by the Worker.
To be conformant to Level 3, a Worker MUST: • • • • •
Conform to Level 2 of this ICS, Be able to receive and execute conformant JMF SubmitQueueEntry Command Messages via HTTP, Be able to receive and respond to conformant JMF KnownDevices, KnownMessages, and SubmissionMethods Query Messages via HTTP, Be able to send out conformant JMF ReturnQueueEntry Command Messages to the Manager via HTTP, and Be able to return or forward the JDF Instance, with specified updates.
1.1.5 Base ICS Level 0 This ICS also defines a level 0 for unidirectional exchange of JDF from Manager to Worker. Level 0 is equivalent to Level 1 except for the following points that relate to returning JDF from Worker to Manager: • A Level 0 Manager NEED NOT consume JDF Instances • A Level 0 Worker NEED NOT produce JDF Instances • The Write conformance for a Worker defaults to w? in section 4 Conformance Tables – JDF Instances. • The Read conformance for a Manager defaults to r? in section 4 Conformance Tables – JDF Instances.
1.1.6 Interoperability of Levels Because of the incremental nature of the ICS levels except for Level 0, a Manager or Worker that conforms to a higher level is able to interoperate with a Worker or Manager, respectively that conforms to a lower level by using this lower level for all communication.
1.2 JDF Instances This ICS specifies the JDF Traits that are common to all areas where JDF is used.
1.3 JMF Messages This ICS specifies the JMF Traits that are common to all areas where JMF is used. This ICS also describes how JMF Messages are used to:
Page 7 of 61
Base ICS, Version 1.0 Errata Revision B • • •
Send Messages from the Producer to the Consumer Submit jobs from the Manager to a Worker, Return jobs from the Worker to the Manager,
This ICS describes the conformance requirements for: • • • •
Command Messages for ReturnQueueEntry, StopPersistentChannel and SubmitQueueEntry Query Messages for KnownDevices, KnownMessages and SubmissionMethods Response Messages for KnownDevices, KnownMessages, ReturnQueueEntry, StopPersistentChannel, SubmissionMethods, and SubmitQueueEntry Acknowledge Messages for SubmitQueueEntry.
Other JMF messages are possible but these are outside the scope of this ICS, but may be included in other ICS documents, for example [MIS-ICS]. This ICS describes both the JMF Message formats and the transfer protocol. This ICS describes the HTTP transfer protocol for JMF messages.
2 Terminology This section defines terminology used throughout ICS’s. The terms appear in alphabetic order. If a word is in bolditalic, it is defined elsewhere in this section. Elsewhere in ICS’s, the first letter of each word of these terms is capitalized. Agent – see section 1.4 “Glossary of Terminology” in the [JDF1.2] and Producer in this section. Abstract Element – an Element that is a placeholder for other Elements and may describe Traits that are common to other Elements. Such other Elements are said to be derived from the Abstract Element. For example, Audit is an Abstract Element. The Created Element and Modified Element are both derived from the Audit Abstract Element. An Abstract Element does not appear in a JDF Instance. Attribute – see the [JDF1.2] section 1.4 Glossary of Terminology Attribute Value – the value of an Attribute. Conformance Level – defines a subset of Conformance Requirements for an ICS. Level-1 Conformance Requirements form a subset of Level-2 Conformance Requirements, and so on for higher levels. Conformance Requirement – a single requirement that a conforming JDF-enabled product must meet. An ICS specifies a set of Conformance Requirements that a conforming JDF-enabled product must meet in order to achieve interoperability with other conforming JDF-enabled products that meet the same Conformance Requirements. Conformance Table – describes the Conformance Requirements for a single Element of a JDF Instance or JMF Message. Each row of a Conformance Table contains a single Trait of the Element. Each such Trait is subject to two Conformance Requirements, one that applies to a conforming Manager and another that applies to a conforming Worker. Consumer – a Manager or Worker in a role where it consumes a JDF Instance or JMF Message, i.e. reads and processes a JDF Instance or JMF Message. See Producer in this section. See also JDF Consumer in the [JDF1.2] section 1.4 Glossary of Terminology. Controller – see the [JDF1.2] section 1.4 Glossary of Terminology Derived Element – an Element that is based on some Abstract Element. See Abstract Element for an example. Device – see the [JDF1.2] section 1.4 Glossary of Terminology Device Worker – the Worker part of a Device. Element – see the [JDF1.2] section 1.4 Glossary of Terminology
Page 8 of 61
Base ICS, Version 1.0 Errata Revision B Hot Folder – a folder that is watched by the Worker, so that when the Manager writes a file into the Hot Folder, the Worker interprets that action as a job submission and attempts to perform the actions specified in the JDF Instance or JMF Message contained in the file. Interoperability Conformance Specification (ICS) – a specification developed by a CIP4 WG and approved by the CIP4 Technical Steering Committee (TSC). An ICS specifies the Manager Conformance Requirements for an interface that a conforming JDF-enabled product must meet in order to achieve interoperability with other conforming JDF-enabled products that meet the corresponding Worker Conformance Requirements. JDF – see the [JDF1.2] section 1.4 Glossary of Terminology JDF Instance – an XML document that is a valid JDF node according to [JDF1.2]. The JDF node describes a print job or some portion thereof. JDF Instance File – a file that contains a JDF Instance only JDF MIME File – a MIME Multipart/Related file [RFC 2387] whose first body part is a JDF Instance and each remaining body part is identified by a Content-ID Header [RFC 2392]and is referenced from the JDF Instance body part using a “cid” URL [RFC 2392]. JMF – see the [JDF1.2] section 1.4 Glossary of Terminology JMF Message – an XML document that is a valid JMF Element according to the JDF Schema. Manager Interface – the interface that sends JDF Instances, JMF Messages and other data (possibly via the network) to a Worker in a Device or Controller in the hierarchy below (see [JDF1.2] Figure 2.1) and may receive information back (possibly via the network) from a Worker in a Device or Controller. Manager – the software that implements the Manager Interface. MAY – see the [JDF1.2] section 1.4.1 Conformance Terminology MIS – see the [JDF1.2] section 1.4 Glossary of Terminology MIS Manager – the Manager part of the MIS. MUST, MUST NOT – see the [JDF1.2] section 1.4.1 Conformance Terminology NEED NOT – indicates an action that is not required for conformance, but MAY be performed. Node – see the [JDF1.2] section 1.4 Glossary of Terminology Producer – a Manager or Worker in a role where it produces or modifies either a JDF Instance or JMF Message, i.e. writes or updates a JDF Instance or JMF Message. See Agent and Consumer in this section. Process: see the [JDF1.2] section 1.4 Glossary of Terminology Product-Sector ICS – an ICS that specifies the Conformance Requirements for a JDF-enabled product in a specific product sector. For example, an ICS for a product sector that includes binding is likely to have a requirement for a Stitching process. Referenced File – a file that is referenced via a URI from a JDF Instance or a JMF Message. For example, a PDF file could be a Referenced File SHOULD – see the [JDF1.2] section 1.4.1 Conformance Terminology Subelement – an Element that is a child of another Element. Support – see the [JDF1.2] section 1.4 Glossary of Terminology Trait – in the context of an Element, a single Subelement of it, a single Attribute of it or a single Attribute Value of one of its Attributes. In the context of the [JDF1.2], a table for an Element contains all Traits of the Element.
Page 9 of 61
Base ICS, Version 1.0 Errata Revision B Worker Interface – the interface that receives JDF Instances, JMF Messages and other data (possibly via the network) from a Manager in a Controller or MIS in the hierarchy above (see [JDF1.2] Figure 2.1) and may send information back (possibly via the network) to a Manager in a Controller or MIS. Worker – the software that implements the Worker Interface
3 Conformance Rules 3.1 Data Type Values This section specifies Conformance Requirements for certain data type values,
3.1.1 Size Limits for Attribute Values The length of every Attribute value(including list types) MUST not exceed 20k characters when the Attribute Value is encoded as an XML string. This limit ensures that the length of its Unicode representation does not exceed 64k.
3.1.1.1 Size Limits for Simple Values Table 1 specifies the minimum and maximum number of characters allowed for values of each specified data type when such a value occurs in an XML document, i.e. a JDF Instance or JMF Message. Note: that this ICS expresses the maximum size of many strings in terms of characters. The number of octets needed per characters varies according to the representation. For example an ASCII character is represented by one octet; a UCS-2 character can be represented directly by two octets or encoded in UTF-8 with 1, 2 or 3 octets depending on the character. Other representations have additional complexity. Thus, if an implementation allocates space for a specified number of octets rather than a specified number of characters, it must know how many octets are needed for each character. Therefore, text data types have been limited to 20K (20480) characters, so that their UTF-8 maximum will never exceed 64K. Table 1: Minimum and Maximum Number of Characters of Specified JDF Data Types
Data Type
Minimum
Maximum
Description
enumeration
1
63
Although the [JDF1.2] enumerates all values and thus limits what can be written in the JDF, this value is useful for a Consumer.
hexBinary
2
20480
A string of an even number characters restricted to contain digits “0” to “9” and letters “a” to “f” (in lowercase or uppercase) Each pair of characters represents the value of an octet.
ID
1
63
IDREF
1
63
NMTOKEN
1
63
PDF Path
0
20480
regExp
1
20480
Regular expression as defined by [XMLSchema].
Page 10 of 61
Base ICS, Version 1.0 Errata Revision B Data Type string
Minimum
Maximum
0
1023
Description A normalizedString [XMLSchema], i.e., character strings without tabs, and line feeds, etc. A number of Attributes that use the string data type MAY be used to index into an internal database. Therefore, such Attributes have a shorter maximum limit than 1023. See Table 3: Attributes with Short String below.
text
0
20480
URI
1
4095
Represents a Uniform Resource Identifier (URI) Reference as defined in Section 4 of [RFC 2396].
URL
1
4095
Represents a Uniform Resource Locator (URL) Reference as defined in Section 4 of [RFC 2396].
XPath
1
20480
Text data contained in a telem (text Element).
Represents a path to an Element or Attribute in an XML document [XPath].
3.1.1.2 Size Limits for Lists Table 2 specifies the minimum and maximum number of units allowed for values of each specified data type when such a value occurs in an XML document, i.e. a JDF Instance. Table 2 also specifies the units. For example, NMTOKENS has a minimum length of 0 NMTOKEN’s (i.e. 0 octets) and a maximum number of 2048 NMTOKEN’s. Because the maximum length of NMTOKEN is 63 and a space character separates each NMTOKEN, the maximum length of NMTOKENS is 2048*(63+1) - 1 = 131,071 characters. Table 2: Minimum and Maximum Size of List-like JDF Data Types
Data Type enumerations
Minimum
Maximum
0
63
Units enumeration
Description Specifies the number of enumeration’s in enumerations Although the [JDF1.2] enumerates all values and thus limits what can be written in the JDF, this value is useful for a reader application.
NMTOKENS
0
2048
NMTOKEN
Specifies the number of NMTOKEN’s in NMTOKENS
SomeTypeList
0
2048
someType
For example, if someType is IntegerRange, then this rule states that an IntegerRangeList contains at most 211 IntegerRange’s, each of which consists of two integers
3.1.1.3 Size Limits for Attributes with Short Strings Some string-valued Attributes identify objects, such as Resources. Such Attributes have a shorter maximum length of 63 or 255 characters rather than the normal maximum length of 1023 for other string-valued Attributes because an implementation may use the Attribute’s string value to index into an internal database. Most of the Attributes in Table 3 below end with “ID”.
Page 11 of 61
Base ICS, Version 1.0 Errata Revision B Table 3: Attributes with Short String
Attribute
Length
BatchID
63
CatalogID
63
CostCenterID
63
CustomerJobName
255
CustomerOrderID
63
CustomerID
63
DefaultID
63
DescriptiveName
Notes
255
DeviceID
63
JMFSenderID
63
JobID
63
JobPartID
63
LocID
63
MountID
63
NextQueueEntryID
63
PersonalID
63
PipeID
63
PrevQueueEntryID
63
ProductID
63
ProjectID
63
QueueEntryID
63
RelatedJobID
63
RelatedJobPartID
63
ResourceID
63
SenderID
63
SpawnID
63
StatusDetails
63
TemplateID
63
ToolID
63
The original JobPartID MUST NOT exceed 50 characters so that a Controller can generate nested JobPartID’s (when not using NewJDF). For details see JobPartID in Table 6: JDF Node.
Page 12 of 61
Base ICS, Version 1.0 Errata Revision B 3.1.1.4 Size Limits for Attributes Named in the PartIDKeys Attribute Table 4 specifies the minimum and maximum number of units allowed for the values of each specified data type when such a value is the value of a Part ID Attribute in either a Part Element or in a partitioned Resource. See Table 328: “Contents of the Part element” in [JDF1.2] for a list of Part ID Attributes and Table 3-27 “Contents of the Partitionable Resource Element” in [JDF1.2] for the values of the PartIDKeys Attribute. If a Part ID Attribute has a data type that is not listed in Table 4, then the data type doesn’t have special size limits, and Table 1 and Table 2 specify the size limits. Table 4: Part ID Attributes – Different Size Limits
Data Type
Minimum
Maximum
Units
1
63
character
string
Description The number of characters in a string is different.
3.2 Hot Folders See Section 2 Terminology for definitions of JDF Instance File, JDF MIME File and Referenced File, all of which appear in the subsections below with hot links on the first occurrence.
3.2.1 Requirements for Managers A Manager MUST be capable of writing a JDF Instance File and MAY be capable of writing a JDF MIME File into a Hot Folder. When a Worker requires that it receive a job via a Hot Folder, a Manager MUST write exactly one file F into a Hot Folder that the Worker controls and file F MUST be either a JDF Instance File or a JDF MIME File. If file F contains references to other files (called Referenced Files) and the receiving Worker Supports Referenced Files, there are three types of Referenced Files to Support. The Manager intends that some files be accessed in their existing location. This specification does not address this case. The Manager intends that some files be accessed in a new location outside the Hot Folder. This specification does not address this case. The Manager intends that some files f1, … fn be accessed via the Hot Folder. The Manager MUST NOT write such files directly into the Hot Folder. Instead, the Manager MUST Support both of the following mechanisms: 1. 2.
Create a directory D within the Hot Folder and write the Referenced Files f1, … fn into the directory D or its sub-directories, and Write the Referenced Files f1, … fn into an existing directory within the Hot Folder in an implementation dependent manner.
Note: a single JDF Instance File or JDF MIME File could contain references to all three types of Referenced Files. Note: a Worker typically Supports only one of the above two mechanisms for writing Referenced Files into a Hot Folder. This document does not specify how a Manager determines the mechanism that a Worker Supports, or how the Manager determines the name of the sub-directory (for either case). A Manager MUST NOT remove any files or directories that are accessible via the Hot Folder, including those files and directories that the Manager writes. Furthermore, the Manager MUST NOT submit multiple jobs that reference the same files in sub-directories of a Hot Folder.
3.2.2 Requirements for Workers A Worker MUST be able to read and process any JDF file in a Hot Folder under its control. The Worker’s Hot Folder MUST be configured for a Manager to write a JDF Instance File into the Hot Folder.
Page 13 of 61
Base ICS, Version 1.0 Errata Revision B In addition, if a Worker Supports Referenced Files, the Worker’s Hot Folder MAY (at Level 3: MUST) be configured for any Manager to write a JDF MIME File into the Hot Folder. In this case, the Worker MUST Support the option below that corresponds to the option above for Managers to write Referenced Files: 1. 2.
Create a directory D: the Hot Folder MUST be configured to allow Managers to create directories within the Hot Folder. Write into an existing directory: the special directory for Referenced Files within the Hot Folder MUST be configured to allow Managers to write files.
If a Worker Supports processes that require Referenced Files, the Worker MUST Support the URLs in Table 5 for accessing Referenced Files from a JDF Instance in any file, whether the file is a JDF Instance File or a JDF MIME File. See also section 6.2 “Plain JDF versus JMF - Submit Queue Entry”. Table 5: Worker Supported Schemes
Name or Value Level Î Any attribute with a Data Type of URL
Manager 1
2
3
Worker 1
2
Description 3
wÍ
r?
If the scheme is not “cid:”, the Manager MUST keep the referenced asset available for the Worker to retrieve at least until the Worker completes or aborts the job.
file:…
wÍ
r
URL whose scheme is “file”.
./…
w?
r
Any Relative URL relative to the Hot Folder. Relative URLs MUST be supported assuming the File: scheme and MAY be supported assuming other schemes. See [FileURL-AN].
http:... cid:…
wÍ
r wÍ
URL whose scheme is “http” r
URL whose scheme is “cid”
Note: A Worker or some companion software typically removes JDF Instance Files and JDF MIME Files along with any Referenced Files and directories from the hot folder at some time after the Worker no longer needs them. However, this ICS specifies no requirements for such file and directory removal, and an implementation may or may not use any housekeeping mechanism that it chooses. For example, an implementation may choose to do no housekeeping. The Worker MUST NOT consult RunList/Disposition and/or FileSpec/Disposition for files in the Hot Folder or its subdirectories.
3.3 JDF Extensions and JDF 1.2 Deprecated items Elements, Attributes or Attribute Values (including NMTOKEN values) that are undefined in the [JDF1.2] or that are deprecated in the [JDF1.2] are optional to read or write (w?/r?). That is, write Support for JDF extensions and deprecated Traits is allowed. Note that interoperability based on such traits might be reduced.
Page 14 of 61
Base ICS, Version 1.0 Errata Revision B
4 Conformance Tables – JDF Instances Each table in this section shows the Conformance Requirements for an Element of a JDF Instance. See Appendix A: “How to Read ICS Documents” for an explanation of the table format and the codes used to specify conformance.
4.1 JDF Node Table 6 specifies the conformance requirements for Attributes and Elements for a JDF Node, whether it is a Root Node or a Subnode. Most of the Attributes and Elements have the same Conformance Requirements whether the node is a Root Node or a Subnode. Those that differ are marked with “wÍ” and the Description column specifies the conditions. The JDF Node requirements for Attributes and Values in Table 6 are fulfilled when the Attributes are specified in the AncestorPool/Ancestor elements and their Subnodes, respectively (see Table 56: Ancestor). Table 6: JDF Node Referenced by: JDF Node
Name or Value Level Î
Manager 1
2
3
Worker 1
2
Description 3
w?
r
Active
wÍ
r
TestRunAndGo
w?
r
A Worker MAY treat TestRunAndGo in the same way as Active.
all remaining values
w?
r
A Worker MUST NOT process tickets that are not active.
w?
r?
Links to a human readable description of the job in any format. This ICS makes no statement about supported formats or how a Worker should deal with the data referenced by the URL.
Activation
CommentURL
See [JDF1.2] section 4.2.1
The job description referenced by this URL does NOT affect the value of any Attributes in the JDF Node, even when there is an apparent name similarity. If the scheme is not “cid”, the Manager MUST keep the Comment available for the Worker to retrieve at least until the Worker completes or aborts the job. file:…
wÍ wÍ
http:...
!w
URL whose scheme is “file” r
wÍ
cid:… all remaining values
r
URL whose scheme is “http” r
r?
Page 15 of 61
URL whose scheme is “cid”
Base ICS, Version 1.0 Errata Revision B Name or Value Level Î
Manager 1
2
3
Worker 1
2
Description 3
DescriptiveName
wÍ
r?
MUST occur in Root Node, indicating a single line Job Title; SHOULD occur in Subnodes with other values. If the Worker identifies the node to an operator, it SHOULD include the DescriptiveName in any such identification. Note: many devices have limited possibilities to display the job description. The string value should be as short as possible.
ICSVersions
wÍ
r?
MUST occur in Root Node, MAY occur in Subnodes. Each NMTOKEN value has the syntax: _L . The Manager MUST supply a set of NMTOKEN values, one for each ICS with which the JDF Instance complies. The NMTOKEN values are unordered. Each ICS specifies only the unique NMTOKEN value(s) that pertain to its domain, even if the ICS requires other ICS’s to be supported.
Base_L0-1.0
w?
r?
Specifies that the JDF node conforms to [BaseICS] level 0. MUST only be specified if unidirectional JDF is acceptable to the Manager.
Base_L1-1.0
w
r?
Specifies that the JDF node conforms to [BaseICS] level 1.
r?
Specifies that the JDF node conforms to [BaseICS] level 2.
r?
Specifies that the JDF node conforms to [BaseICS] level 3.
wÍ
r?
Values specified in other ICS’s
ID
w r?
r wÍ
MUST be supplied if a new node is created. MUST NOT be modified.
JobID
wÍ
r
MUST occur in Root Node, MAY occur in Subnodes.
w
Base_L2-1.0
w
Base_L3-1.0 all remaining values
Page 16 of 61
Base ICS, Version 1.0 Errata Revision B Name or Value Level Î JobPartID
Manager 1 w r
2
3
Worker 1
2
Description 3
r wÍ
Each JDF Node (Product, Process Group, Combined Process, and Process) MUST have a JobPartID and its value MUST be unique within the context of all JDF Instances that have the same JobID in the print shop’s workflow. When creating JDF sub-nodes, a worker MUST generate the new JobPartID by adding a suffix to the parent JDF node’s JobPartID. Each suffix MUST start with a period “.” and MUST NOT exceed 3 characters including the period. The resulting JobPartID MUST NOT exceed 63 characters. Note: JobPartID is required even at the root level
wÍ
r
w
r
w r?
r w
wÍ r?
r wÍ
w
r
wÍ r?
r? w?
1.2
w r?
r? w
xmlns
wÍ
r?
MaxVersion 1.2 Status all values Type Version
MUST be in Root Node, MAY be in Subnodes.
See [JDF1.2] sections 3.1.2 and 4.3, and section A.2 of this document.
As specified in [JDF1.2] MUST be in Root Node, MAY be in Subnodes. See [JDF1.2] section 3.11 for information about versioning.
MUST be in Root Node, MAY be in Subnodes. The namespace for JDF may be the default namespace or any prefixed namespace.
w
r?
Note: that for all 1.x versions of [JDF1.2], the namespace URI is the same
wÍ
r?
MUST be in Root Node, MAY be in Subnodes.
w
r?
xsi:type
w
r?
Helps JDF Schema aware implementations to identify specific node types.
AncestorPool
w?
r
See Table 55: AncestorPool
http://www.CIP4.org/JDFSch ema_1_1 xmlns:xsi http://www.w3.org/2001/XML Schema-instance
MUST only be specified in the root node of a spawned JDF. AuditPool
w r?
r? w
Page 17 of 61
See Table 10: AuditPool
Base ICS, Version 1.0 Errata Revision B Name or Value Level Î JDF
Manager 1 w?
2
3
Worker 1
2
Description 3
r
Child JDF Node(s) See Table 6: JDF Node
NodeInfo
w?
r
See Table 7: NodeInfo
ResourceLinkPool
wÍ
r
In general a ResourceLinkPool is required, except for a Gray Box that doesn’t have linked resources.
ResourcePool
wÍ
r
The MIS and Product-Sector ICS’s specify particular Resource children of this Element.
StatusPool
wÍ r?
r wÍ
The StatusPool MUST be updated if AncestorPool/Part is specified. MIS and Product-Sector ICS’s specify particular StatusPool children of this Element See Table 8: StatusPool.
Page 18 of 61
Base ICS, Version 1.0 Errata Revision B Table 7: NodeInfo Referenced by: JDF Node
Name or Value Level Î
Manager 1
2
3
w?
TargetRoute
Worker 1
2
Description 3
r
Where the Worker returns or forwards the JDF after processing. If TargetRoute is not supplied, the Worker MUST send the completed JDF according to [JDF1.2] TargetRoute description. A Worker that only complies to Level 0 of this ICS NEED NOT Support TargetRoute. If JMF/QueueSubmissionParams/ @ReturnJMF or JMF/ QueueSubmissionParams/@ReturnURL is supplied, then the Worker MUST ignore TargetRoute.
file:
wÍ
r
all remaining values
!w
r?
JMF
w?
URL whose scheme is “file”
r
This JMF Element is an alternate way for a Manager to start a Persistent Channel. For level 2, this mechanism allows a Manager to send JMF to Worker without using HTTP. The Worker MUST close the Persistent Channel when the node is completed or aborted. The Worker MUST NOT respond to this JMF with a Response JMF. See Table 20: JMF
Table 8: StatusPool Referenced by: JDF Node
Name or Value Level Î
Manager 1
2
3
Worker 1
wr
rw
Pool
!w r?
r? !w
All other values
wÍ r
r wÍ
wÍ r
r wÍ
Status
PartStatus
2
Description 3
Page 19 of 61
Not allowed in StatusPool
See Table 9: PartStatus
Base ICS, Version 1.0 Errata Revision B Table 9: PartStatus Referenced by: StatusPool
Name or Value Level Î
Manager 1
2
3
Worker 1
wr
rw
Pool
!w r?
r? !w
all remaining values
wÍ r
r wÍ
wr
rw
Status
Part
2
Description 3
Not allowed in PartStatus
The part of the process that the Status Attribute applies to. Other ICS’s specify the attributes for the Part Element.
4.2 AuditPool This section specifies the AuditPool. See other ICS’s, such as the [MIS-ICS], for additional AuditPool requirements. Note: In this section, the Conformance-Table columns for Manager and Worker are relabeled Producer and Consumer. When a Manager writes JDF, it is the Producer and the Worker is the Consumer. When a Worker writes JDF, it is the Producer and the Manager is the Consumer. Table 10: AuditPool Referenced by: JDF Node
Name or Value Level Î
Producer
Consumer
1
1
2
3
2
Description
3
Created
w
r?
See Table 12: Created
Modified
w?
r?
SHOULD supply if significantly modifying the JDF See Table 13: Modified
Page 20 of 61
Base ICS, Version 1.0 Errata Revision B Table 11: Audit – Abstract Referenced via: AuditPool
Name or Value Level Î
Producer
Consumer
1
1
2
3
AgentName
w
r?
AgentVersion
w
r?
TimeStamp
w
r?
2
Description
3
Table 12: Created Derived from: Audit . Name or Value Level Î
Producer
Consumer
1
1
2
3
2
Description
3 Created Audits have no required Traits other than those defined in Table 11: Audit – Abstract
Table 13: Modified Derived from: Audit Name or Value Level Î
Producer
Consumer
1
1
2
3
2
Description
3 Modified Audits have no required traits other than those defined in Table 11: Audit – Abstract.
Page 21 of 61
Base ICS, Version 1.0 Errata Revision B
4.3 Resource This section defines general conformance requirements for Resources. It specifically defines the conformance requirements pertaining to partitioning of Resources. Any conforming Consumer of JDF MUST support reading of partitioned Resources and behave in a manner that is specified in section 3.8 of [JDF1.2]. Table 14: Resource Referenced by: ResourcePool
Name or Value Level Î
Manager 1
2
3
Worker 1
2
Description 3
ID
w r?
r wÍ
MUST be supplied if a new Resource is created. MUST NOT be modified.
PartIDKeys
wÍ
r
Partitioned resources MUST contain a PartIDKeys attribute with values as specified in section 3.8.2 of [JDF1.2]. Further ICS’s may restrict the list of allowed values of PartIDKeys for a given resource.
PartUsage
w?
r
Both Implicit and Explicit partitioning MUST be supported.
Status
w r
r wÍ
A Worker MUST update the Status of any Resource that it produces as output to Available. A Worker SHOULD update the Status of any Resource that it consumes completely as input to Unavailable.
Page 22 of 61
Base ICS, Version 1.0 Errata Revision B Table 15: ResourceLink Referenced by: ResourceLinkPool
Name or Value Level Î
Manager 1
2
3
Worker 1
2
Description 3
ActualAmount
wÍ r?
r wÍ
A Worker MUST update the ActualAmount of any physical Resource that it produces or consumes. See [JDF1.2] 3.8.1 for details.
Amount
wÍ
r?
A Manager MUST specify the amount to be produced in a ResourceLink of the output Resource to be produced. See [JDF1.2] 3.8.1 for details.
w
r
This Attribute MUST reference a Resource that is a direct child of a ResourcePool
rSubRef
!w
r?
The Manager MUST NOT supply this Attribute because this ICS does not allow a ResourceLink to reference sub-elements of a Resource.
Usage
w
r
See [JDF1.2]
wÍ
r
A Worker MUST read and support ResourceLink attributes that apply to one or more partitions of a Resource, if it processes physical Resources.
rRef
AmountPool
See Table 16: AmountPool Part
w?
r
A Worker MUST read and support ResourceLinks that reference one or more partitions of a resource.
Table 16: AmountPool Referenced by: ResourceLink
Name or Value Level Î PartAmount
Manager 1 w
2
3
Worker 1
2
Description 3
r
Page 23 of 61
See Table 17: PartAmount
Base ICS, Version 1.0 Errata Revision B Table 17: PartAmount Referenced by: AmountPool
Name or Value Level Î
Manager 1
2
3
Worker 1
2
Description 3
ActualAmount
w? r?
r wÍ
A Worker MUST update the ActualAmount of any physical Resource that it produces or consumes. See [JDF1.2] 3.8.1 for details.
Amount
wÍ
r?
A Manager MUST specify the amount of the output resource to be produced. See [JDF1.2] 3.8.1 for details.
Part
w?
r
A Worker MUST read and support ResourceLinks that reference one or more partitions of a Resource.
4.4 ResourceRef A ResourceRef element may occur where [JDF1.2] specifies a data type of refElement. Conforming Consumers MUST support reading ResourceRef elements wherever a data type of refElement is specified in [JDF1.2]. Table 18: ResourceRef
Name or Value Level Î
Manager 1
2
3
Worker 1
2
Description 3
w
r
This Attribute MUST NOT reference a Resource that is a sub-element of another Resource. In a JDF the referenced Resource MUST be a direct child of a ResourcePool. In a JMF the referenced Resource MUST be the direct child of either ResourceInfo or ResourceCmdParams.
rSubRef
!w
r?
The Manager MUST NOT supply this Attribute because this ICS does not allow a ResourceRef to reference sub-elements of a Resource.
Part
w?
r
A Worker MUST read and support References to a partition of a Resource.
rRef
Page 24 of 61
Base ICS, Version 1.0 Errata Revision B
4.5 Device Implementation Resource This section defines general conformance requirements for the Device Implementation Resource, which a Manager MAY supply in any Process or ProcessGroup node. See section 6.1 “Complete Job Instance versus a (spawned) Process Node”, [JDF1.2] section 3.6.1.3 “Implementation Resources”, [JDF1.2] section 7.2.50 “Device”, and [JDF1.2] section 4.2.1 “Determining Executable Nodes”). Table 19: Device Referenced by: ResourcePool, ResourceLinkPool
Name or Value Level Î
Manager 1
2
3
wÍ
DeviceID
Worker 1
2
Description 3
r
DeviceID MUST be specified if an individual Device is targeted. Device clusters MAY be specified using other Device attributes.
5 Conformance Tables – JMF Messages This section contains Conformance Tables that specify conformance requirements for JMF Messages: Note: For sections 5.1, 5.2 , and some of the sub-sections in section 5.4, the Conformance Table columns for Manager and Worker are relabeled Producer and Consumer. When a Manager sends a JMF Message to a Worker, the Manager is the Producer and the Worker is the Consumer. When a Worker sends a JMF Message to a Manager, the Worker is the Producer and the Manager is the Consumer. The note at the beginning of sub-section 5.4 provides the mapping between the Manager/Worker and the Producer/Consumer.
5.1 Root Node of a JMF message This section contains the Conformance Table for the JMF element that is the Root Node of any JMF message, whether sent by HTTP or as part of a JDF Instance (JDF/NodeInfo/JMF). Table 20: JMF Root Node of a JMF message Referenced by: NodeInfo
Name or Value Level Î
Producer
Consumer
1
1
2
3
2
Description
3
DeviceID
w?
r
The value identifies the JMF’s intended recipient If the immediate Consumer or any subsequent recipient does not recognize the JMF/@DeviceID value, it SHOULD reject the message with ReturnCode=”121” (See Appendix B: .
SenderID
w
r?
Identifies the sender. Each Controller/Device SHOULD use a fixed sender ID. The SenderID MUST be the DeviceID of the sender.
Page 25 of 61
Base ICS, Version 1.0 Errata Revision B Name or Value Level Î
Producer
Consumer
1
1
2
3
2
Description
3
TimeStamp
w
r?
Version
w
r?
w
r?
wÍ
r?
The namespace for JDF may be the default namespace or any prefixed namespace. MUST be present in the JMF Root of a JMF message, but NEED NOT be present in a JDF Instance (JDF/NodeInfo/JMF).
w
r?
Note: that for all 1.x versions of [JDF1.2], the namespace URI is the same
wÍ
r?
MUST be present in the JMF Root of a JMF message, but NEED NOT be present in a JDF Instance (JDF/NodeInfo/JMF).
w
r?
w
r
1.2 xmlns
http://www.CIP4.org/JDFSch ema_1_1 xmlns:xsi
http://www.w3.org/2001/XML Schema-instance Message
Date and time the JMF is sent
Abstract Element(s) See Table 21: Message – Abstract for Attributes common to all Messages. See Table 27: Message – Derived Message Families
Page 26 of 61
Base ICS, Version 1.0 Errata Revision B
5.2 Conformance requirements for JMF Message Families This section contains Conformance Tables that specify conformance requirements for the 5 JMF Message families. Table 21: Message – Abstract Referenced by: JMF
Name or Value Level Î
Producer
Consumer
1
1
2
3
2
Description
3
Time
wÍ
r?
Type
w
r
xsi:type
w
r?
Helps JDF Schema aware implementations to identify specific message types.
w
r
Example: CommandSubmitQueueEntry
Time at which the message was generated. This attribute MUST be specified if different from JMF/@TimeStamp.
“Command” is Message Family Name. See column 1 of Table 27: Message – Derived Message Families . “SubmitQueueEntry” is the Message’s /JDF/Message/@Type. See Table 47: Command – SubmitQueueEntry.
Table 22: Query – Abstract Derived From: Message
Name or Value Level Î
Producer
Consumer
1
1
2
3
2
Description
3
QueryTypeObj
wÍ
r
Abstract element that is a placeholder for any descriptive elements that provide details required for the query.
Subscription
wÍ
r
A Consumer MUST support this Element for establishing a persistent channel, See other ICS’s for Subscription contents.
Page 27 of 61
Base ICS, Version 1.0 Errata Revision B In Table 23: Response – Abstract, the Producer is the producer of the Response and the Consumer is the consumer of the original Response. Thus the roles have been exchanged with respect to the original Command or Response tables. Table 23: Response – Abstract Derived From: Message
Name or Value Level Î
Producer
Consumer
1
1
2
3
2
Description
3
Acknowledged
wÍ
r
The Producer MUST supply this Attribute with a value of “true” when it will send an asynchronous Acknowledge later.
refID
wÍ
r
See [JDF1.2].
ReturnCode
wÍ
r
A non-zero return code indicates failure. If an error occurs, a Producer MUST write a nonzero value. See Appendix B: and [JDF1.2] Appendix I for a list of supported values. A Consumer MUST be able to detect nonzero values. How a Consumer handles nonzero value is implementation dependent.
Subscribed
wÍ
r?
true
wÍ
r? A level 3 Producer MUST accept Subscriptions for Persistent Channels in Queries.
The Producer MUST supply this Attribute if the Query contained a Subscription (see Table 22: Query – Abstract)
Table 24: Signal – Abstract Derived From: Message
Name or Value Level Î
Producer
Consumer
1
1
2
3
2
Description
3
LastRepeat
wÍ
r?
If the Producer has closed the Persistent Channel the value of this Attribute MUST be “true”,
refID
wÍ
r
If the Signal is a result of a Subscription, the Producer MUST supply the ID of the Subscription Query
Page 28 of 61
Base ICS, Version 1.0 Errata Revision B Table 25: Command – Abstract Derived From: Message
Name or Value Level Î
Producer
Consumer
1
1
2
3
2
wÍ
AcknowledgeURL
Description
3 r? If a Producer allows the Consumer to send an Acknowledge, the Producer MUST supply this Attribute.
Table 26: Acknowledge – Abstract Derived From: Message
Name or Value Level Î
Producer
Consumer
1
1
AcknowledgeType all values refID ReturnCode
2
3
2
Description
3
wÍ
r
wÍ
r
w
r
ID of the Command message.
wÍ
r
A non-zero return code indicates failure. If an error can occur, a Producer MUST be capable of writing at least one nonzero value. See Appendix B: and [JDF1.2] Appendix I for a list of supported values. A Consumer MUST be able to detect nonzero values. How a Consumer handles nonzero value is implementation dependent
5.3 JMF Handshaking 5.3.1 Persistent Channels – Creating and Closing A Worker sends JMF Signals to a Manager in what is called a Persistent Channel. A Manager creates a Persistent Channel and enables the sending of JMF Signals by sending a Query Message with a Subscription Element to the Worker. In this ICS, a Level 2 Manager MUST send the Query Message as a subelement of the JDF/NodeInfo element in the JDF Instance (see Table 7: NodeInfo). A Level 3 Manager MAY send the Query Message either as a subelement of JDF/NodeInfo in the JDF Instance or as a separate JMF Query message via HTTP. This ICS does not specify any specific Query Message or Subscription to establish a Persistent Channel (see other ICS’s). A Level 2 Worker MUST accept Subscriptions as a subelement of JDF/NodeInfo in the JDF Instance. The Worker MUST close the Persistent Channel that is set up through the JDF/NodeInfo when execution of the node completes or is aborted.
Page 29 of 61
Base ICS, Version 1.0 Errata Revision B If a Level 3 Manager is capable of sending a Query with Subscriptions via HTTP, the Manager MUST also be capable of sending a StopPersistentChannel Command. If a Level 3 Worker accepts a Query with Subscriptions via HTTP, the Worker MUST accept a StopPersistentChannel Command.
5.3.2 Asynchronous Acknowledges A Consumer of a JMF Command message MUST respond by returning a ResponseTypeObj by one of two mechanisms: a synchronous one or an asynchronous one. If a Consumer responds synchronously, it MUST • • •
Include a ResponseTypeObj in a Response Element, Include the Response Element in an HTTP response Send the HTTP response to respond to the Command in the HTTP request.
If a Consumer responds asynchronously, it MUST • • • •
Include the Response Element (that MAY contain a ResponseTypeObj)in an HTTP response Send the HTTP response to respond to the Command in the HTTP request. Include a ResponseTypeObj in an Acknowledge Element, Send one or more Acknowledge Messages as separate JMF Messages.
5.4 Individual Message Types Table 27: Message – Derived Message Families defined the conformance requirements for individual message types. Note: Table 27 provides the mapping between the Manager/Worker and the Producer/Consumer. •
If the Manager column contains a “write” for a Message, then the Manager is a Producer and the Worker is a Consumer for that Message. For example, for a SubmitQueueEntry Command, the Manager that is acting as a Producer sends a Message to a Worker acting as a Consumer.
•
If the Manager column contains a “read” for a Message, then the Worker is a Producer and the Manager is a Consumer for that Message. For example, for a SubmitQueueEntry Response, the Worker that is acting as a Producer sends a Message to a Manager acting as a Consumer.
Note: The first column of Table 27 specifies the name of the Message Family. The second column of Table 27 specifies the value of the /JMF/Message/@Type Attribute, i.e., it specifies the particular Message. The Type defined in Table 27 defines the types that are required by this ICS but does not limit further ICS’s from specifying conformance for additional Message Types.
Page 30 of 61
Base ICS, Version 1.0 Errata Revision B Table 27: Message – Derived Message Families Referenced by: JMF
Message Family Name Query
@Type Level Î KnownDevices
Manager 1
2
3 w? r
Worker 1
2
Description 3
r Non-Device Workers MUST be w? capable of sending. See Table 28: Query – KnownDevices
Response
KnownDevices
r? w
w See Table 30: Response – r? KnownDevices
Query
KnownMessages
w? r
r Non-Device Workers MUST be w? capable of sending. See Table 34: Query – KnownMessages
Response
KnownMessages
r? w
Command
ReturnQueueEntry
r
w
See Table 38: Command – ReturnQueueEntry
Response
ReturnQueueEntry
w
r
See Table 40: Response – ReturnQueueEntry
Command
StopPersistentChannel
wÍ
w See Table 36: Response – r? KnownMessages
r? Manager MUST be capable of sending if it supports a Query with Subscriptions. Worker MUST support if it accepts a Query with Subscriptions. See Table 41: Command – StopPersistentChannel
Response
StopPersistentChannel
r?
Query
SubmissionMethods
w?
r
See Table 44: Query – SubmissionMethods
Response
SubmissionMethods
r?
w
Table 45: Response – SubmissionMethods
Command
SubmitQueueEntry
w
r
See Table 47: Command – SubmitQueueEntry
Response
SubmitQueueEntry
r
w
See Table 50: Response – SubmitQueueEntry
Acknowledge
SubmitQueueEntry
r
Page 31 of 61
wÍ See Table 43: Response – StopPersistentChannel
w? See Table 54: Acknowledge – SubmitQueueEntry
Base ICS, Version 1.0 Errata Revision B 5.4.1 KnownDevices Note: In this section, the Conformance-Table columns for Manager and Worker are relabeled Producer and Consumer. When a Manager sends a JMF Message to a Worker, the Manager is the Producer and the Worker is the Consumer. When a Worker sends a JMF Message to a Manager, the Worker is the Producer and the Manager is the Consumer.
5.4.1.1 Query – KnownDevices Table 28: Query – KnownDevices Query – Abstract
Derived From:
Name or Value Level Î
Producer
Consumer
1
1
2
Type Query xsi:type QueryKnownDevices DeviceFilter
3
2
Description
3
w
r
w
r
w
r?
w
r
w
r
See Table 29: DeviceFilter
Table 29: DeviceFilter Referenced by: Query – KnownDevices
Name or Value Level Î
Producer
Consumer
1
1
2
3
2
3
w
r
None
!w
r?
Brief
wÍ
r
Details
wÍ
r
DeviceDetails
Description
Page 32 of 61
If Brief is specified, the Consumer MUST return DeviceInfo/Device/@DeviceID in the response.
Base ICS, Version 1.0 Errata Revision B 5.4.1.2 Response – KnownDevices Note: the Producer in the following Response tables is returning the response to the Consumer that initiated the KnownDevices Query, i.e., to the Producer in the KnownDevices Query tables above. Table 30: Response – KnownDevices Derived From: Response – Abstract
Name or Value Level Î
Producer
Consumer
1
1
2
Type KnownDevices xsi:type ResponseKnownDevices DeviceList
3
2
Description
3
w
r
w
r
w
r?
w
r
w
r
See Table 31: DeviceList
Table 31: DeviceList Referenced by: Response – KnownDevices
Name or Value Level Î
Producer
Consumer
1
1
2
DeviceInfo
3
2
w
Description
3 r
See Table 32: DeviceInfo
Table 32: DeviceInfo Referenced by: DeviceList
Name or Value Level Î Device
Producer
Consumer
1
1
2
3 wÍ
2
Description
3 r
If Query/DeviceFilter/@DeviceDetails is not equal to "None" or "Brief", then the Producer MUST return at least one Device element. See Table 33: Device – KnownDevices
Page 33 of 61
Base ICS, Version 1.0 Errata Revision B Table 33: Device – KnownDevices Referenced by: DeviceInfo
Name or Value Level Î
Producer
Consumer
1
1
2
3
2
Description
3
DeviceID
w
r
JDFErrorURL
w?
r
JDFInputURL
w?
r
JDFOutputURL
w?
r
JDFVersions
w?
r
JMFSenderID
w
r
JMFURL
w
r
If the Device sends its own JMF Messages, the value of JMFSenderID MUST match the value of DeviceID.
5.4.2 KnownMessages Note: In this section, the Conformance-Table columns for Manager and Worker are relabeled Producer and Consumer. When a Manager writes JDF, it is a Producer and the Worker is the Consumer. When a Worker writes JDF, it is the Producer and the Manager is the Consumer.
5.4.2.1 Query – KnownMessages Table 34: Query – KnownMessages Derived From: Query – Abstract
Name or Value Level Î
Producer
Consumer
1
1
2
3
2
3
w
r
w
r
w
r?
QueryKnownMessages
w
r
KnownMsgQuParams
w
r
Type KnownMessages xsi:type
Description
Page 34 of 61
See Table 35: KnownMsgQuParams
Base ICS, Version 1.0 Errata Revision B Table 35: KnownMsgQuParams Referenced by: Query – KnownMessages
Name or Value Level Î
Producer
Consumer
1
1
2
3
2
Description
3
wÍ
r
false
wÍ
r
true
w?
r? Implementing Capabilities in KnownMessages is optional at all levels.
Exact
ListCommands
w?
r
ListQueries
w?
r
ListSignals
w?
r
Persistent
w?
r
5.4.2.2 Response – KnownMessages Note: the Producer in the following Response tables is returning the response to the Consumer that initiated the KnownMessages Query, i.e., to the Producer in the KnownMessages Query tables above. Table 36: Response – KnownMessages Derived From: Response – Abstract
Name or Value Level Î Type KnownMessages xsi:type ResponseKnownMessages MessageService
Producer
Consumer
1
1
2
3
2
Description
3
w
r
w
r
w
r?
w
r
w
r
Page 35 of 61
See Table 37: MessageService
Base ICS, Version 1.0 Errata Revision B Table 37: MessageService Referenced From: Response – KnownMessages
Name or Value Level Î
Producer
Consumer
1
1
2
3
2
Description
3
Acknowledge
wÍ
r
See [JDF1.2] 5.5.1.4 for write condition.
Command
wÍ
r
See [JDF1.2] 5.5.1.4 for write condition.
Persistent
wÍ
r
See [JDF1.2] 5.5.1.4 for write condition.
Query
wÍ
r
See [JDF1.2] 5.5.1.4 for write condition.
Signal
wÍ
r
See [JDF1.2] 5.5.1.4 for write condition.
Type
w
r
5.4.3 ReturnQueueEntry 5.4.3.1 Command – ReturnQueueEntry Table 38: Command – ReturnQueueEntry Derived From: Command – Abstract
Name or Value Level Î
Manager 1
2
3
Worker 1
2
Description 3
r
w
r
w
r?
w
CommandReturnQueueEntry
r
w
ReturnQueueEntryParams
r
w
Type ReturnQueueEntry xsi:type
Page 36 of 61
See Table 39: ReturnQueueEntryParams
Base ICS, Version 1.0 Errata Revision B Table 39: ReturnQueueEntryParams Referenced by: Command – ReturnQueueEntry
Name or Value Level Î
Manager 1
2
3
Worker 1
2
Description 3
Aborted
r?
wÍ
Completed
r?
wÍ
QueueEntryID
r?
w? The Worker SHOULD fill in this value. Note that QueueEntryID was erroneously omitted in the original [JDF1.2] but added in the errata to [JDF1.2].
URL
r
w
References JDF Instance.
r
w
URL whose scheme is “cid”
cid:…
5.4.3.2 Response – ReturnQueueEntry Table 40: Response – ReturnQueueEntry Derived From: Response – Abstract
Name or Value Level Î Type ReturnQueueEntry xsi:type ResponseReturnQueueEntry
Manager 1
2
3
Worker 1
2
Description 3
w
r
w
r
w
r?
w
r
Page 37 of 61
Base ICS, Version 1.0 Errata Revision B 5.4.4 StopPersistentChannel 5.4.4.1 Command – StopPersistentChannel Table 41: Command – StopPersistentChannel Command – Abstract
Derived From:
Name or Value Level Î
Manager 1
2
3
Worker 1
2
Description 3
ID
w
r
Type
w
r
w
r
w
r?
w
r
w
r
StopPersistentChannel xsi:type CommandStopPersistentChan nel StopPersChParams
See Table 42: StopPersChParams
Table 42: StopPersChParams Referenced by: Command – StopPersistentChannel
Name or Value Level Î
Manager 1
2
3
Worker 1
2
Description 3
ChannelID
w?
r
The /JMF/Query/@ID in the Query Message that the Manager sent to create a Persistent Channel.
MessageType
w?
r
A Worker must support MessageType for any message type that it supports for Subscriptions
DeviceID
w?
r
URL
w?
r
URL of the receiver of the messages
w
r
URL whose scheme is “http”
http://… all remaining values
!w
r?
Page 38 of 61
Base ICS, Version 1.0 Errata Revision B 5.4.4.2 Response – StopPersistentChannel Table 43: Response – StopPersistentChannel Derived From: Response – Abstract
Name or Value Level Î
Manager 1
2
Type StopPersistentChannel xsi:type ResponseStopPersistentChann el
3
Worker 1
2
Description 3
r
w
r
w
r?
w
r
w
5.4.5 SubmissionMethods 5.4.5.1 Query – SubmissionMethods Table 44: Query – SubmissionMethods Derived From: Query – Abstract
Name or Value Level Î Type SubmissionMethods xsi:type QuerySubmissionMethods
Manager 1
2
3
Worker 1
2
Description 3
w
r
w
r
w
r?
w
r
Page 39 of 61
Base ICS, Version 1.0 Errata Revision B 5.4.5.2 Response – SubmissionMethods Table 45: Response – SubmissionMethods Derived From: Response – Abstract
Name or Value Level Î
Manager 1
2
Type SubmissionMethods xsi:type ResponseSubmissionMethods SubmissionMethods
3
Worker 1
2
Description 3
r
w
r
w
r?
w
r
w
r
w
See Table 46: SubmissionMethods
Table 46: SubmissionMethods Referenced From: Response – SubmissionMethods
Name or Value Level Î
Manager 1
2
3
Worker 1
2
Description 3
HotFolder
r
w
Packaging
r
wÍ See [JDF1.2] 5.6.4.8 for write condition.
URLSchemes
r
wÍ See [JDF1.2] 5.6.4.8 for write condition.
Page 40 of 61
Base ICS, Version 1.0 Errata Revision B 5.4.6 SubmitQueueEntry 5.4.6.1 Command – SubmitQueueEntry Table 47: Command – SubmitQueueEntry Derived From: Command – Abstract
Name or Value Level Î
Manager 1
2
3
Worker 1
2
Description 3
AcknowledgeURL
w
Type
w
r
w
r
w
r?
w
r
w
r
See Table 48: QueueSubmissionParams
wÍ
r
It is highly recommended that the Manager supply this Element
SubmitQueueEntry xsi:type CommandSubmitQueueEntry QueueSubmissionParams QueueFilter
r? A Worker MAY respond synchronously if it accepts queue entries and parses the JDF within the time frame of an http connection. If a Worker chooses to acknowledge a SubmitQueueEntry, it SHOULD Acknowledge in a timely fashion and not wait until it executes the node.
See Table 49: QueueFilter
Page 41 of 61
Base ICS, Version 1.0 Errata Revision B Table 48: QueueSubmissionParams Referenced by: Command – SubmitQueueEntry
Name or Value
Manager
Level Î
1
2
3
Worker 1
2
Description 3
w
r
w
r
ReturnURL
!w
r?
URL
w
r
References a JDF Instance. If the scheme is not “cid”, the Manager MUST keep the JDF available for the Worker to retrieve until the Worker completes or aborts the job as indicated by sending the updated JDF with a ReturnQueueEntry command.
file:…
wÍ
r
URL whose scheme is “file”
ftp:…
w?
r? URL whose scheme is “ftp”
http:...
wÍ
r
URL whose scheme is “http”
cid:…
wÍ
r
URL whose scheme is “cid”
ReturnJMF http:…
!w
all remaining values
URL whose scheme is “http”
r?
Table 49: QueueFilter Referenced by: Command – SubmitQueueEntry
Name or Value Level Î
Manager 1
2
3
Worker 1
2
Description 3
MaxEntries
w?
r
QueueEntryDetails
w?
r
Page 42 of 61
To reduce the number of Queue entries returned in the Response to the SubmitQueueEntry Command, it is highly recommended that the Manager supply MaxEntries
Base ICS, Version 1.0 Errata Revision B 5.4.6.2 Response – SubmitQueueEntry The Worker MUST return a SubmitQueueEntry Response before the HTTP connection would time out. In addition, the Worker MUST parse the JDF supplied in the SubmitQueueEntry. If the Worker is unable to parse the JDF before returning the SubmitQueueEntry Response, the Worker MUST return the Response followed by a SubmitQueueEntry Acknowledge after the Worker has parsed the JDF (see section 5.3.2 “Asynchronous Acknowledges” and Table 54: Acknowledge – SubmitQueueEntry). Table 50: Response – SubmitQueueEntry Derived From: Response – Abstract
Name or Value Level Î Type SubmitQueueEntry xsi:type ResponseSubmitQueueEntry QueueEntry
Manager 1
2
3
Worker 1
2
Description 3
r
w
r
w
r?
w
r
w
r
wÍ The Worker MUST write this Element unless the Command failed (@ReturnCode != 0). See Table 51: QueueEntry
Queue
r?
wÍ The Worker MUST write this Element unless the Worker is sending this Element asynchronously via an Acknowledge Message instead. See Table 52: Queue
Page 43 of 61
Base ICS, Version 1.0 Errata Revision B Table 51: QueueEntry Referenced by: Response – SubmitQueueEntry, Acknowledge – SubmitQueueEntry
Name or Value Level Î
Manager 1
2
Worker
3
1
2
r?
JobID
Description 3
wÍ MUST be specified in a Response if it has Acknowledged="false", otherwise MUST be specified in a subsequent Acknowledge Message. If the Worker has parsed the JDF, the Worker MUST return the JobID of the Root Node that was passed in the SubmitQueueEntry.
r?
JobPartID
wÍ MUST be specified in a Response if it has Acknowledged="false", otherwise MUST be specified in a subsequent Acknowledge Message. If the Worker has parsed the JDF, the Worker MUST return the JobPartID of the Root Node that was passed in the SubmitQueueEntry.
QueueEntryID
r
w
Status
r
w
Waiting
r
wÍ If a QueueEntry is being parsed between Response and Acknowledge, the Status MUST be Waiting.
Running
r
wÍ
r?
wÍ The Part elements are copies of AncestorPool/Part of the JDF node that is executed by the Device.
Part
Table 52: Queue Referenced by: Response – SubmitQueueEntry, Acknowledge – SubmitQueueEntry
Name or Value Level Î
Manager 1
2
3
Worker 1
2
Description 3
Status
r?
w
DeviceID
r?
w
Device
r?
w? See Error! Reference source not found.
QueueEntry
r?
wÍ See [JDF1.2] 5.6.3.10 for details. See Table 53: QueueEntry – Queue
Page 44 of 61
Base ICS, Version 1.0 Errata Revision B Table 52a: Device – Queue Referenced by: Queue
Name or Value
Manager
Level Î
1
2
3
Worker 1
2
r?
DeviceID
Description 3
w
The device that executes entries in this queue.
Table 53: QueueEntry – Queue Referenced by: Queue
Name or Value
Manager
Level Î
1
2
3
Worker 1
2
Description 3
QueueEntryID
r?
w
Status
r?
w
r?
wÍ
r?
wÍ The Part elements are copies of AncestorPool/Part of the JDF node that is executed by the Device
all values Part
5.4.6.3 Acknowledge – SubmitQueueEntry
Table 54: Acknowledge – SubmitQueueEntry Derived From: Acknowledge – Abstract
Name or Value Level Î Type SubmitQueueEntry xsi:type AcknowledgeSubmitQueueEnt ry QueueEntry
Manager 1
2
3
Worker 1
2
Description 3
r
w
r
w
r?
w
r
w
r
wÍ The Worker MUST NOT supply this Element if the Command fails. See Table 51: QueueEntry
Queue
r?
w
Page 45 of 61
See Table 52: Queue
Base ICS, Version 1.0 Errata Revision B
6 Conformance Tables – Job Submission 6.1 Complete Job Instance versus a (spawned) Process Node When creating a JDF, the Manager has two options: • •
Create a complete JDF Instance with all information for all Devices; or Create multiple JDF Instances, one for each target Device, with only the information required by the target Device. A Manager can create this type of JDF Instance by spawning off the individual Process Node(s) that the target Device requires.
To be conformant to this ICS, the Device MUST be able to read and process both kinds of JDF Instances. If a Device receives a complete JDF Instance, it MUST be able execute the JDF Instance. For details see [JDF1.2] 4.2.1. A JDF Instance MAY include more than one Process Node for a target Device. To be conformant to this ICS, a Device MUST be able to execute multiple Process Nodes from a JDF Instance. For details see [JDF1.2] section 4.2.1 where DeviceCap/@ExecutionPolicy = "AllFound". The Manager MAY target a JDF Node to a specific device by linking a Device Resource to the JDF Node (see section 4.5 “Device Implementation Resource”).
6.1.1 AncestorPool The information about ancestor JDF nodes in a spawned job MUST be specified in the AncestorPool/Ancestor elements. For details see [JDF1.2] section 4.4. A conforming reader MUST be capable of extracting information from the AncestorPool. Table 55: AncestorPool Referenced by: JDF Node
Name or Value Level Î Ancestor Part
Manager 1
2
3
Worker 1
2
Description 3
w
r
See Table 56: Ancestor
wÍ
r
The Part element contains the partition attributes that are filled in Status messages, PartStatus, Audits etc.
Page 46 of 61
Base ICS, Version 1.0 Errata Revision B Table 56: Ancestor Referenced from: AncestorPool
Name or Value Level Î
Manager 1
2
3
Worker 1
2
Description 3
All attributes defined in Table 6: JDF Node.
wÍ
r?
The conformance requirements that are defined in Table 6: JDF Node apply to Attributes and their values in Ancestor.
NodeInfo
w?
r
The conformance requirements that are defined in Table 7: NodeInfo apply to the NodeInfo in Ancestor.
6.2 Plain JDF versus JMF - Submit Queue Entry When a Manager submits a JDF Instance to a Worker, the Manager has two options: • •
Place the JDF Instance directly into the Hot Folder of the Device without JMF SubmitQueueEntry; Submit a JMF SubmitQueueEntry Message.
To be compliant to Level 1 and 2 of this ICS, both the Manager and the Device Worker MUST support JDF Hot Folders (see section 3.2 Hot Folders). To be Compliant to Level 3 of this ICS, both Manager and the Device Worker MUST support Hot Folders and the JMF Command SubmitQueueEntry.
6.2.1 URL External Reference versus MIME Encoded When a Manager submits a JDF Instance via a JMF SubmitQueueEntry message, the Manager has two options: • •
The JDF Instance is a part of the JMF Message. The JMF Message Element and the JDF Instance are each a body part of a Multipart/Related entity. The JDF Instance is separate from the JMF Message. The JMF Message uses a URL to reference a file containing a JDF Instance.
To be conformant to Level 3 of this ICS, a Manager MUST support both of the options in the previous paragraph and a Worker MUST be able to accept both of the options in the previous paragraph. This ICS enforces a restriction of a single SubmitQueueEntry Command per JMF Message.
Page 47 of 61
Base ICS, Version 1.0 Errata Revision B
7 References 7.1 Normative References [JDF1.2]
“Job Definition Format (JDF), Version 1.2”, published May 7, 2004 and “Errata”, JDF Specification Release 1.2. Available at: http://www.cip4.org.
[JDF-logo]
“CIP4 Guidelines: For CIP4 and JDF Logo Use”, April 14, 2004, to be updated to include ICS conformance. Available at: http://www.cip4.org.
[RFC2387]
Levinson, E., "The MIME Multipart/Related Content-type", RFC 2387, August 1998.
[RFC2392]
Levinson, E., "Content-ID and Message-ID Uniform Resource Locators", RFC 2392, August 1998.
[RFC2396]
Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform Resource Identifiers (URI): Generic Syntax", RFC 2396, August 1998
[XPath]
Clark, James and Steve DeRose, XML Path Language (XPath) http://www.w3.org/TR/1999/RECxpath-19991116, 16 November 1999
[XMLSchema]
Biron, Paul V., Ashok Malhotra , XML Schema Part 2: Datatypes http://www.w3.org/TR/xmlschema-2, 02 May 2001
7.2 Informative References [JDF1.3]
“Job Definition Format (JDF), Version 1.3”, published September 30, 2005 and “Errata”, JDF Specification Release 1.3. Available at: http://www.cip4.org.
[FileURL-AN]
“CIP4 Application Note: Use of the File URL in JDF”. Published 12 November 2003. Available at: http://www.cip4.org.
[MIS-ICS]
“MIS ICS”, Version 1.0, published December 2005. Available at: http://www.cip4.org.
Page 48 of 61
Base ICS, Version 1.0 Errata Revision B
Appendix A: How to Read ICS Documents A.1 Overview This appendix explains how to read ICS documents and defines the notation used in the Conformance Tables of all ICS documents.
A.1.1 Need for Multiple ICS’s Although a single ICS that encompasses all JDF-enabled products might appear to be the best solution, such an ICS would burden JDF-enabled products with the necessity of implementing many unneeded Conformance Requirements. For example, a Stitching process for JDF-enabled products in the postpress sector would add unneeded complexity to JDF-enabled products in the conventional printing sector. Hence, there is a need for a separate ICS for each product sector; product sectors include prepress, digital printing, conventional printing and postpress. Each such ICS defines a subset of JDF for all JDF-enabled products in its product sector.
A.1.2 Avoiding Replication of Conformance Requirements If Conformance Requirements for each product sector were described by a single ICS, some Conformance Requirements would be replicated in many of the Product-Sector ICS’s. To avoid replication, common Conformance Requirements can be factored out and placed into another ICS. In particular, Conformance Requirements that are common to all Product-Sector ICS’s have been factored out and placed in a separate ICS – the [Base-ICS] (this document). Common Conformance Requirements that are MIS in nature and are not in the [BaseICS] have been factored out from the Product-Sector ICS’s and placed in a separate ICS – the [MIS-ICS]. Conformance requirements that are in common with any ICS and the [JDF1.2] have been factored out from the ICS. Here are some examples: • • •
The [JDF1.2] specifies the maximum value for an integer type but does not specify the maximum length of a string. No ICS replicates such information about an integer. However, the [Base-ICS] does specify the maximum length of a string. If an ICS specifies Support for an Element and the [JDF1.2] specifies that some of its Attributes are required, the ICS is silent about those Attributes to avoid replicating Conformance Requirements of the [JDF1.2]. If an ICS specifies Support for an Element and the [JDF1.2] specifies that some of its Attributes are optional, the ICS is silent about those Attributes that remain optional in the ICS to avoid replicating Conformance Requirements of the [JDF1.2].
Some product sectors have a wide range of JDF-enabled products, from simple to complex. To accommodate this range of capabilities, there is a need for multiple sets of Conformance Requirements. There could be a separate ICS for each set of Conformance Requirements. Instead, there is a single ICS that specifies multiple sets of Conformance Requirements. Each set is called a Conformance Level. Conformance level 1 specifies Conformance Requirements for the simplest JDF-enabled products. Conformance level 2 specifies Conformance Requirements for more complex JDF-enabled products; the Conformance Requirements are a superset of the level-1 Conformance Requirements. Conformance level 3 specifies Conformance Requirements for even more complex JDF-enabled products; the Conformance Requirements are a superset of the level-2 Conformance Requirements. The [JDF1.2], the [Base-ICS], the [MIS-ICS] and all the Product-Sector ICS’s with their levels form a relationship that is similar to a protocol stack as shown in Figure 1.
Page 49 of 61
Base ICS, Version 1.0 Errata Revision B Figure 1: Example of an ICS Stack
top
Integrated Digital Printing ICS
MIS to Prepress ICS
Conventional Printing – Sheet Fed ICS
mid-high
Binding ICS
MIS ICS [MIS-ICS]
mid-low
Base ICS (described in this document)
bottom
[JDF1.2]
A.1.3 Ramifications for Implementers Because ICS’s are purposefully not redundant, an implementer of a JDF-enabled product must consult the following documents in order to get a complete picture: • • •
The appropriate Product-Sector ICS. All ICS’s referenced by the Product-Sector ICS, including the [Base-ICS] and possibly the MIS ICS. The parts of the [JDF1.2] referenced from a relevant ICS, such as definitions of Elements and data types.
For example, if an implementer wants to know what parts of the Component Resource to implement for a Binding product, the implement would need to read all information in the following places: Binding ICS sections: Component, ComponentLink – Input and ComponentLink – Output. MIS ICS sections: Component – Output and Component-Link – Output. Base ICS sections: Resource and ResourceLink. [JDF1.2] sections: Component, PhysicalResource, Resource, ComponentLink, PhysicalLink and ResourceLink
A.1.4 Ramifications for Vendors In order for a vendor to claim conformance to CIP4 ICS’s for a particular JDF-enabled product, such a claim MUST identify the Product-Sector ICS (title and version) that the JDF-enabled product conforms to, along with a Conformance Level. A Product-Sector ICS specifies the other documents (titles and versions) that the ICS draws from, such as the [MIS-ICS], the [Base-ICS] and [JDF1.2].
A.2 Interfaces for Conformance Requirements The [JDF1.2] defines a hierarchical relationship of workflow components, which include the MIS, Controllers and Devices. See [JDF1.2] Figure 2.1. A Device is at the bottom of the hierarchy. It initiates a process and may send information back up the hierarchy about the results of initiating the process. A Controller is somewhere above the bottom of the hierarchy. It causes some Device or other Controller to initiate a process, and may receive information back from the Device or other Controller about the initiated process. It may then send this information back up the hierarchy. The MIS is at the top of this hierarchy and acts as the master Controller. Each workflow component in this hierarchy is connected to other workflow components, possibly via the network. The [JDF1.2] defines an additional workflow component called an Agent. An Agent can write JDF. It can create JDF nodes or it can modify existing JDF nodes. In most cases, the software that implements an MIS, Controller or Device also implements an Agent. In this hierarchical model, a Controller deals with workflow components above it and below it. An MIS deals only with workflow components below it and a Device deals only with workflow components above it. This observation suggests an interface for dealing with workflow components above, and another interface for dealing with workflow components below. In this document, the term Manager Interface describes the interface that deals with workflow components below, and the term Worker Interface describes the interface that deals with workflow components
Page 50 of 61
Base ICS, Version 1.0 Errata Revision B above. In [JDF1.2] Figure 2.1, wherever an arrow comes from below, there is a Manager Interface and wherever an arrow comes from above, there is a Worker Interface. Note: these two interfaces are much like the typical client and server interfaces. That is, the Manager Interface (like a client interface) provides a service for the MIS or Controller software. When MIS or Controller software invokes a method of this Manager Interface, the method invocation causes (via some implementation dependent series of actions) some corresponding (but different) method in the Worker Interface (like a server interface) to be invoked, thus causing the Controller or Device software to take some action. To put it succinctly, the ICS defines behavior and the [JDF1.2] defines the format and semantics of data passed between the Manager Interface and the Worker Interface. Controller software along with its Agent software MUST implement both the Manager Interface and the Worker Interface. Device software along with its Agent software MUST implement the Worker Interface, but not the Manager Interface. An MIS MUST implement the Manager Interface. Note, in the context of the described hierarchy, an MIS does not implement the Worker Interface. A Manager is software that implements the Manager Interface, and a Worker is software that implements a Worker Interface. The remaining paragraphs of this section describe the behavior of a Manager and Worker at a high level. The Conformance Requirements in the ICS’s specify the detailed behavior, such as exactly what Attributes and Elements a Manager MUST write in a JDF Instance or what mechanism a Worker MUST use to receive a JDF Instance. A Manager MUST (in the order specified) be able to: 1. 2. 3. 4.
Create or modify JDF Instances Send JDF Instances and other data (possibly via the network) to a Worker in a Controller or Device that is lower in the hierarchy Receive JDF Instances back (possibly via the network) from a Worker in a Controller or Device that is lower in the hierarchy Optionally read the received JDF Instances.
If a Manager supports JMF Messages, then the statements in the above list are true when each occurrence of “JDF Instances” in the above list is replaced with “JMF Messages”. A Worker MUST (in the order specified) be able to: 1. 2. 3. 4.
Receive JDF Instances (possibly via the network) from a Manager in a Controller or MIS that is higher in the hierarchy Read the JDF Instances and other data and cause them to be processed optionally create, or modify JDF Instances, including correctly updating JDF node and Resource Status. Send JDF Instances and JMF Messages back (possibly via the network) to a Manager in a Controller or MIS that is higher in the hierarchy
If a Worker supports JMF Messages, then the statements in the above list are true when each occurrence of “JDF Instances” in the above list is replaced with “JMF Messages”. Note: if a workflow component contains both Manager and Worker software (e.g. a Controller), the complete Manager Interface and complete Worker Interface will typically be specified by a different set of ICS’s. In a Controller: 1. 2.
The Worker can transfer (internally) JDF nodes that it receives from above (possibly over the network) to its associated Manager that sends below. The Manager can transfer JDF nodes that it receives from below (possibly over the network) to its associated Worker that sends above
Page 51 of 61
Base ICS, Version 1.0 Errata Revision B
A.3 Content of Conformance Tables Section 4 “Conformance Tables” contains a series of Conformance Tables that specify the Conformance Requirements for various Elements and their Traits. This section describes the content and format of Conformance Tables. Other ICS’s have similar Conformance Tables for Elements. In addition some ICS’s have Conformance Tables for Input and Output Resources of Processes. Each Conformance Table for an Element describes the Conformance Requirements for a single Element of a JDF Instance or JMF Message. Each row of a Conformance Table contains a single Trait of the Element. Each such Trait is subject to up-to twelve Conformance Requirements, up-to six that apply to a conforming Manager and an up-to another six that apply to a conforming Worker. Up to two Conformance Requirements apply to each Conformance Level – one for reading the Trait and the other for writing the Trait. In most cells, at least one Conformance Requirement is unspecified, i.e. left blank (See Table 58, Table 59 and Table 60) Likewise, each Conformance Table for Resources of a Process describes the Conformance Requirements for all input Resources of a particular Process or all output Resources of a particular Process. Each row of a Conformance Table contains a single Resource of the Process. Each such Resource is subject to up-to twelve Conformance Requirements as described for Elements in the preceding paragraph. Each Conformance Table for an Element contains all Traits that a conforming implementation MUST Support except for those Traits that meet the condition described in the next paragraph. Likewise, each Conformance Table for Resources of a Process contains all Resources that a conforming implementation MUST Support except for those Resources that meet the condition described in the next paragraph. When a table contains an Abstract Element, another table lists the Conformance Requirement for (some of) its Derived Elements. The Conformance Requirements of each Derived Element in such a table are similar to those of Conformance Tables for Elements. If [JDF1.2] or a lower ICS (i.e. lower in the hierarchy as shown in Figure 1) requires a Trait in an Element or a Resource in a Process, then a Conformance Table omits the Trait or Resource unless the Conformance Table provides additional information. Here are two examples. If [JDF1.2] requires that a Manager supply an Attribute and the ICS requires that a Manager supply certain Attribute Values, the Attribute is present in the Conformance Table. If [JDF1.2] requires that a Manager supply an Element and the ICS requires a Manager to supply certain otherwise optional Traits within the Element or descendants, the Element is in a Conformance Table. In other words, if an ICS requires support for a Trait T that is optional in [JDF1.2], the ICS Conformance Tables contain all Traits that form the path to Trait T. If [JDF1.2] states that a Trait in an Element or a Resource in a Process is optional and no lower ICS requires it, then the Trait or Resource is optional. Important Observation: the absence of a Trait from an ICS has two very different meanings. If Trait X (of Element E) or Resource X (of Process P) is absent from a Conformance Table of an ICS, then X (i.e. Trait X or Resource X) is: Required or Conditionally Required if [JDF1.2] or a lower ICS requires or conditionally requires it (X). Optional if [JDF1.2] specifies that X is optional and all lower ICS’s either are silent about X or specify that X is optional. The “?” in the Name Column in [JDF1.2] generally means that the Trait is optional. However, the Description column may state that a Trait is conditionally required. For such an example, see ResourceLink/@ProcessUsage in [JDF1.2]. The Conformance Requirement for each Trait and each Resource is the same whether the JDF is transmitted via Hot Folder or via JMF. The Conformance Requirement for any Trait is always conditioned by the Conformance Requirement for its containing Element. Likewise, the Conformance Requirement for any Resource of a Process is always conditioned by the Conformance Requirement for the Process. For example, if a Manager is required to write some Attribute, but that Attribute is contained in an optional Element that the Manager chooses not to write, then the Manager doesn’t write the required Attribute either.
Page 52 of 61
Base ICS, Version 1.0 Errata Revision B A.3.1 Format of Conformance Tables The format of each Conformance Table is similar to the tables for Elements and Process Resources in the [JDF1.2]. In the [JDF1.2], most Element tables have three columns: Name, Data Type and Description with Attribute Values in the Description Column. The ICS Conformance Tables for Elements have no Data Type column and combine the names and values into a Name or Value column. In addition, the ICS Conformance Tables have two additional columns between the Name or Value and Description columns. Each of these two columns has 3 sub-columns. Table 57 describes the format of Conformance Tables. The ICS Conformance Tables for Process Resources are similar to ICS Conformance Tables for Elements; except that they have no values. Table 57: Format of Conformance Tables
Item
Column Name
Description
Table Caption
The caption specifies the Element or Process Resource described by the table. For example “Media” for an Element table or “Folding – Input Resources” for a Process Resources table.
Reference Line
One or more Reference Lines, just below the Table Caption, have hot links to other tables that contain a reference to this table. Words in bold describe the relationship of the reference, such as Referenced by or Derived from.
1st column
Name or Value (the row has a white background)
1st column
Name or Value
(alternative)
(the row has a light gray background)
For an Element table, when this column has a white background, it is like the Name column in the [JDF1.2]. It contains Attribute names, followed by Element names, each in alphabetic order.
For an Element table, when the row has a light gray background, the cell in the Name or Value column contains either one Attribute value or (for NMTOKENS and enumerations) one NMTOKEN or enumeration value. When a Conformance Table specifies the values of an Attribute, the values appear in a series of contiguous, light gray rows starting just below the row for the Attribute. Each value appears without quotes, as in the [JDF1.2]. If no attribute values are specified for a given attribute, a conforming application MUST Support at least one valid attribute value as defined by [JDF1.2] or a higher level ICS. For NMTOKENS and enumerations, the [JDF1.2] and possibly the Attribute’s Description cell specify the combinations of values (in rows) that comprise an NMTOKENS or enumerations Attribute Value. There are two special Attribute Values: all values: a shorthand for a series of rows that enumerate all values of an Attribute as specified by [JDF1.2]. Each row has one value as specified by the earlier paragraphs of this cell. all remaining values: identical in meaning to all values, except that the Attribute has some explicitly specified values as well. This value is always the last value listed for an Attribute.
Page 53 of 61
Base ICS, Version 1.0 Errata Revision B Item
Column Name
Description
1st column
Name
(alternative)
(different column title)
2nd column
Manager
Each of the 3 sub-columns of this column is for a different Conformance Level. Each sub-column specifies exactly two Conformance Requirements that apply to a conforming Manager – one for writing (see Table 59) and one for reading (see Table 60). The specified Trait or Resource is subject to these Conformance Requirements. An ICS always specifies Conformance Requirements for Level 1. If an ICS doesn’t specify Conformance Requirements for Level 2, all sub-columns for Level 2 are left blank – likewise for Level 3.
3rd column
Worker
Replace the word “Manager” with the word “Worker” in the above cell.
2 column (alternative)
Producer
Note: In some tables, the Conformance Table columns for Manager and Worker are relabeled Producer and Consumer (in italics). When a Manager writes JDF/JMF, it is a Producer and the Worker is the Consumer. When a Worker writes JDF/JMF, it is the Producer and the Manager is the Consumer.
3rd column (alternative)
Consumer
See above cell.
4th column
Description
Cells in this column are blank, unless there is information beyond [JDF1.2]. For example, the description of a Trait or Resource might reference another Conformance Table, or specify a condition for writing it.
nd
For a Process Resources table, this column has Resource names.
A.3.2 Conformance Requirements for Writing and Reading Two of the following three sections describe the reading and writing values that can appear in the six Manager and Worker sub-columns of a Conformance Table. Table 59 in section A.3.2.2 shows values for writing a Trait or Resource. Table 60 in section A.3.2.3 shows values for reading a Trait or Resource. Table 58 in section A.3.2.1 shows the meaning of a blank cell in one of these six sub-columns. The Conformance Requirements are usually symmetric. For example, if a Conformance Requirement for writing a Trait applies to a Manager, then there is usually a Conformance Requirement for reading a Trait that applies to a Worker. Note: in this section, Element E refers to the Element specified by the Conformance Table’s caption, and Trait T in Element E is some Element, Attribute or Attribute Value in Element E’s Conformance Table. Process P refers to the Process specified by the Conformance Table’s caption and Resource R is some Resource in Process P’s Input Resources Conformance Table or Output Resources Conformance Table.
Page 54 of 61
Base ICS, Version 1.0 Errata Revision B A.3.2.1 Blank Cell for a Conformance Level Table 58 specifies the meaning of a blank cell for each Conformance Level. Table 58: Blank Cell for a Conformance Level
Level
Description
1
A blank Conformance Level 1 cell means that the ICS does not specify Conformance Requirements for Level 1.
2
Blank Conformance Level 2 and Level 1 cells mean that the ICS specifies Conformance Requirements for neither Level 1 nor Level 2. Otherwise, a blank Conformance Level 2 cell has the value of the adjacent nonblank Conformance Level 1 cell if the ICS specifies a Conformance Level 2.
3
A blank Conformance Level 3 cell has the value of the adjacent Conformance Level 2 cell if the ICS specifies a Conformance Level 3.
A.3.2.2 Conformance Requirements for Writing All columns of Table 59 except the first column explain the meaning of the value in the first column. Table 59 lists the Conformance Requirements for writing in descending order of strength from “w” (the strongest) to “!w” (the weakest). Table 59 contains the following columns: Value: the value that can appear in any of the six Manager and Worker sub-columns of a Conformance Table. Can Write: succinctly specifies whether the Manager Producer or Worker Producer is capable of writing a specified Trait Does Write: succinctly specifies whether the Manager Producer or Worker Producer actually writes a specified Trait Description: describes the behavior of a Producer if it supplies Element E and E’s Trait T is marked with the specified value (from the Value column of Table 59) in the Conformance Table or if it supplies Process P and P’s Resource R is marked with the specified value (from the Value column of Table 59) in the Conformance Table. Because a Conformance Table is either for Element E or Process P, the phrase “Trait T in Element E” in Table 59 also means “Resource R in Process P”.
Page 55 of 61
Base ICS, Version 1.0 Errata Revision B Table 59: Conformance Requirements for Writing
Value
Can Write
Does Write
w
MUST
MUST
Description The Producer MUST write Trait T in Element E. If a Trait is an Element, its Description Column in a Conformance Table may use the word update or supply. The word update means that a Producer updates the existing Element and its descendants as specified by their Conformance Tables. The word supply (or the lack of the word update) means that a Producer creates the Element as specified by its Conformance Table. Parts of or all of the Element may reference existing Element(s) (see [JDF1.2]). If an Element is a Resource, the Producer creates additional structure (see [JDF1.2]. If both the Manager and Worker column have a “w” (or a “wÍ” or “w?” that is effectively a “w”), then the two “w”s mean “The Manager supplies and the Worker updates” unless otherwise noted in an ICS. A single “w” means either “The Manager supplies” or “The Worker supplies” depending on the column of the “w”. If the EBNF in the Name column of [JDF1.2] specifies "*" or “+”, a "w" means that the Producer MUST write at least one Trait. Note: an ICS uses the “w” for an Attribute Value only if it is the sole value allowed for a Conformance Level or if it is a required NMTOKEN for an NMTOKENS value or a required enumeration for an enumerations value.
wÍ
MUST
MAY
The Producer MUST write Trait T in Element E, if some runtime condition is met. The condition is always specified in the Description column of the Conformance Table with the following exceptions. If an Attribute with a specified default value has no explicit condition, the implicit condition is “the Producer’s implementer chooses whether to supply or not supply the Attribute when its value is the default value. The Consumer MUST behave the same in both cases.” If an Attribute Value has no explicit condition, the implicit condition is “as specified by [JDF1.2]”. If the Attribute Value is a default value, its additional implicit condition is “the Producer MUST be capable of supplying this value if and only if it supplies the Attribute when its value is the default value” A Producer determines if some runtime condition is met by executing some software test. For example, the Producer’s test might: Request that a human operator select some option in a GUI Determine if some other JDF Attribute has a certain value. Determine if some value is present in some file Query the network for the presence of some device. Note: all of these examples illustrate testable conditions. See the above cell (for “w”) for a definition of update and supply. Note: “BÍ A” in logic means “B if A”. So “wÍ” means “write if some condition in the Description column is met”.
w?
MAY
MAY
The Producer MAY write Trait T in Element E. An ICS may provide a condition that an implementer uses to decide whether to write software that supplies the Trait.
Page 56 of 61
Base ICS, Version 1.0 Errata Revision B Value
Can Write
Does Write
!w
MUST NOT
MUST NOT
Description The Producer MUST NOT create, modify or erase the Trait T in Element E or Resource R in Process P. This requirement is used to disallow writing of the Trait or Resource. Note: “!A” in programming means “not A”. So “!w” means “don’t write”. The Conformance Table cell is left blank with regard to writing but has an “r” or “r?”. Such a cell has an implicit “w?” unless prohibited by [JDF1.2].
A.3.2.3 Conformance Requirements for Reading All columns of Table 60 except the first column explain the meaning of the value in the first column. Table 60 lists the Conformance Requirements for reading in descending order of strength from “r” (the strongest) to “r?” (the weakest). Table 60 contains the following columns: Value: the value that can appear in any of the six Manager and Worker sub-columns of a Conformance Table. Can Read: succinctly specifies whether the Manager Consumer or Worker Consumer is capable of reading and Supporting a specified Trait upon receiving it. Description: describes the behavior of a Consumer if it reads Element E and E’s Trait T is marked with the specified value (from the Value column of Table 60) in the Conformance Table or if it reads Process P and P’s Resource R is marked with the specified value (from the Value column of Table 60) in the Conformance Table. Because a Conformance Table is either for Element E or Process P, the phrase “Trait T.” in Table 60 also means “Resource R”. Table 60: Conformance Requirements for Reading
Value
Can Read
Description
r
MUST
The Consumer MUST read and Support Trait T The [JDF1.2] defines “Support” in section 1.4 and 1.4.2. to mean perform the action defined in [JDF1.2]. If an Attribute is marked with an “r” and there are no values rows listed under it in the ICS, then the Consumer MUST support at least one value.
r?
MAY
The Consumer MAY read and Support Trait T. Some “r?” rows have an explicit condition in the Description that applies to the Consumer. If the condition is true, the Consumer MUST Support the Trait. The Trait MAY be Supported, but if Supported, any contained Traits MUST be Supported according to their conformance requirements.
MAY
The Conformance Table cell is left blank with regard to reading but has a “w”, “wÍ”, “w?” or “!w”. Such a cell has an implicit “r?”.
Page 57 of 61
Base ICS, Version 1.0 Errata Revision B
Appendix B: Additional Supported Error Codes in JMF and Notification elements This Appendix contains additional error codes that can be supplied in JMF/Acknowledge/@ReturnCode or JMF/Response/@ReturnCode. These error codes were not defined in JDF 1.2 but are valid error codes in ICS compliant applications and are defined in [JDF1.3]. Table 61: Additional JMF Error Codes
ReturnCode
Description
116
Queue entry already exists. Used when a QueueEntry with identical JobID, JobPartID and Part already exists. Cannot access URL. URI reference cannot be resolved. Used when a referenced entity, e.g. a JDF in a SubmitQueueEntry cannot be found. Unknown DeviceID. No Device is known with the DeviceID specified.
120 121
Page 58 of 61
Base ICS, Version 1.0 Errata Revision B
Appendix C: Errata Revision A, 2005-12-05 The following section summarizes normative errata that were found after publication of the Base ICS 1.0, 2004-1222: Location
Description
1. Section 1.1.5 Base ICS Level 0
Simplified/clarified that Level 0 Managers NEED NOT read and Level 0 Workers NEED NOT write any JDF.
2. Section 1.3 JMF Messages
First bullet, changed “signal” to “Messages”.
3. Section 3.3 JDF Extensions
Removed requirements for a "Conformance Mode".
4. Table 19: Device
Removed “Queue” from Referenced by, since errata has added Error! Reference source not found. for use by Queue.
5. Table 20: JMF
DeviceID: Changed “wÍ” to “w?”.
6. Table 20: JMF
SenderID: Changed the “should” to “SHOULD” to follow the conventions for conformance words.
7. Table 20: JMF
xmlns and xmlns:xsi: Changed “w” to “wÍ” and added the condition: MUST be present in JDF Root of a JMF message, but NEED NOT be present in a JDF Instance (JDF/NodeInfo/JMF) in order to agree with XML standard.
8. Table 22: Query – Abstract
QueryTypeObj: Changed “w?” to “wÍ” for the Producer, since the condition depends on the actual message.
9. Section 5.4 Individual Message Types
Removed statement that this ICS only supports SubmitQueueEntry and ReturnQueueEntry, since the conformance tables require other messages as well.
10. Table 29: DeviceFilter
DeviceDetails: changed “wÍ” to “w” since the Manager MUST supply a value in order to override the default of “None”, which this ICS forbids (“!w”). Also changed the two values (“Brief” and “Full”) from “w?” to “wÍ” following the conventions for all other single valued “w” attributes that have multiple values listed in an ICS.
11. Table 29: DeviceFilter
DeviceDetails=”Brief”: Clarified that it is the Consumer that MUST specify DeviceInfo/Device/@DeviceID (in the response).
12. Section 5.4.1.2 Response – KnownDevices: Table 30: Response – KnownDevices, Table 31: DeviceList, Table 32: DeviceInfo, and Table 33: Device – KnownDevices
Swapped the "r" and "w" between the Producer and Consumer columns and added the Note at the beginning of the sections, since the Producer in a response is the one sending ("w") the response to the Consumer (that initiated the KnownDevices and KnownMessages Query) according to the definitions of Producer and Consumer. Otherwise, Table 20: JMF wouldn’t also apply to the response to a command or query.
13. Section 5.4.2.2 Response – KnownMessages: Table 36: Response – KnownMessages and Table 37: MessageService 14. Section 5.4.4.2 Response – StopPersistentChannel: Table 43: Response – StopPersistentChannel
Page 59 of 61
Base ICS, Version 1.0 Errata Revision B Location
Description
15. Table 32: DeviceInfo
Device: Changed “Details” to “Brief” to agree with [JDF1.2] that requires the Consumer to return Device for all DeviceDetails values, except “None” and “Brief”.
16. Table 39: ReturnQueueEntryParams
Added @QueueEntryID to identify the QueueEntry that has completed or aborted. It’s a [JDF1.2] spec Errata as well.
17. Table 52: Queue
Device: Changed the table reference from Table 33: Device – KnownDevices (which has a number of "w" entries for the Producer) to a new table: Table 52a: Device – Queue (which has only DeviceID with a "w" for the Worker) to agree with [JDF1.2]. [JDF1.2] says that only DeviceID SHOULD be returned in a SubmitQueueEntry response for the Device that services the queue.
18. Table 52a: Device – Queue
Added this new Table 52a: Device – Queue which has the Worker only returning the Device/@DeviceID attribute for the Queue in SubmitQueueEntry response for reference from Queue/Device element in Table 52: Queue. Note: The new table is numbered “52a”, instead of “53”, so that following tables are NOT renumbered. Other documents, such as the “ICS Overview” document, refer to tables in the Base ICS by number.
Page 60 of 61
Base ICS, Version 1.0 Errata Revision B
Appendix D: Errata Revision B, 2006-02-19 The following section summarizes normative errata that were found after publication of the Base ICS 1.0 Errata Revision A, 2005-12-05: Location
Description
1. Table 20: JMF
DeviceID: Deleted: “Only present when the Consumer is a Controller.” since the Producer MAY also supply JMF/@DeviceID when the Consumer is a Device.
2. Table 20: JMF
DeviceID: Replaced: “The value identifies the JMF’s targeted Device.” with: “The value identifies the JMF’s intended recipient.” since JMF/@DeviceID could also be a ControllerID value for an upstream or downstream Controller or an upstream MIS that is the intended recipient of the JMF message.
3. Table 20: JMF
DeviceID: Added: “If the immediate Consumer or any subsequent recipient does not recognize the JMF/@DeviceID value, it SHOULD reject the message with ReturnCode=”121” (see Appendix B: ).”
4. Table 21: Message – Abstract and Table 24: Signal – Abstract
Time: Moved from Table 24: Signal – Abstract to Table 21: Message – Abstract, so that it applies to all Messages, not just Signals. Changed the Producer conformance from “w” to “w
