Although the introduction in the PWG Print Job Ticket and Associated
Capabilities is very informative, it brings to the fore an area of confusion
that may not be mine alone and may affect the adoption of the PWG Print Job
Ticket as a mechanism for printer characteristics (not just capabilities)
communication and job intent communication in a cloud environment.
What the document describes appears to be an abstract structure rather than
a specific entity. Thus the statement "PrintJobTickets are used in a number
of ways associated with the PrintJob" . Specifically identified uses are
"representation of the defaults" (DefaultJobTicket?) and "in the submission
of a PrintJob". Also identified as using the PrintJobTicket structure
(although perhaps with different datatypes) are the PrintJobReceipt and
PrintJobTicketCapabilities. All these may be assumed to be specific
entities, associated with either a specific submitted print job
request/print job or a specific print service.
The entity "used in a job submission protocol to carry the User's request."
is presumably what is referred to as the "submitted PrintJobTicket". Is this
the same as the "accepted PrintJobTicket"? Or is the "accepted
PrintJobTicket" the same as the "PrintJob's PrintJobTicket" ? And them
there is the Job Template which presumably is a Job Ticket not bound to a
job (or service). (And since, some have maintained that a Print Job does not
exist until a Print Job Request is accepted by a Print Service, is what is
submitted with a print job request a Print Job Template?)
Looking for clarification on what is meant by Job Ticket in approved MFD
documents, the Scan Service Specification has this definition:
"Scan Job Ticket - A Scan Job Ticket is a data object that contains an End
User's Scan Intent for document processing, job processing and descriptive
job properties of a Scan Job. The job elements apply to the entire Scan Job.
The document processing elements will be used for all the Documents within
the Scan Job unless overridden at the Document level (See
ScanDocumentTicket). The content of a ScanJobTicket is configured by End
User through a Scan Client."
The Resource Service Specification has this definition:
"Job Ticket - A data object that contains the user's intent for job-level
document processing, job processing and descriptive properties of a job of a
Service. ."
(should that have been "Job or a Service?)
And the Model Specification has this definition
"Job Ticket - A data object that contains a User's Job-level Intent for
Document processing, Job processing and descriptive Job properties of a Job,
sent to an MFD Service. Job Elements apply to the entire Job. Document
processing Elements apply to all Documents within the Job unless overridden
at the Document level (See Document Ticket). The content of a Job Ticket is
configured by a User through a Client. "
>From the model viewpoint, it may be reasonable to say that a PrintJobTicket
is data object with defined format and contents, and that instances of a
PrintJobTicket can be used in several places including Job Request, Job
tracking within a Print Service , PrintJobDefaults, definition of
PrintJobTicketCapabilities, PrintJobReceipts etc., and wherever else it may
be used. (or some more correct statement). Indeed. Such a description
showing how the various applications of the PrintJobTicket are related and
perhaps derived from each other would be useful. As far as I know, we have
not defined a JobTicket that way elsewhere; we have said that the JobTicket
is used to communicate the user's intent in submitting a job request.
However, with all respect for those who have defined the semantic Model, I
think that for Cloud use, it is particularly important that we define the
contents of an object with a specific name that is used to define user
intent in a job request; and that we define the contents of a similar
object with a different name that is used to specify the available
capabilities along with necessary additional information about the Print
Service. The current document, with perhaps some more information clarifying
the uses of the <service>JobTicket, would be a very useful addition to the
revised Model specification. But I suggest that the specification of a PWG
PrintTicket for Job Request Submission and a PWG Printer characteristics
object be a simpler and more explicit presentation of these specific
applications of the general PrintJobTicket data object.
Thanks,
Bill Wagner
--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.pwg.org/pipermail/cloud/attachments/20111025/3ab2d747/attachment-0001.html>