I suggest that the discussion remain on the list in that it is useful for
many, particularly those who have not participated in the MFD group. Some
of us have been indoctrinated into Pete's model to various degrees, but I
sometimes get the impression that people are agreeing with things that are
proposed while having a somewhat different concept, particularly of what a
job is and when it is created. Hopefully the job ticket specification can be
made sufficiently complete to avoid confusion between the PWG model and
others. For example, I was confused about the contention that there were
multiple print job tickets associated with a given print job, although this
was clarified to mean (I think) that there were multiple data objects of
the data type printjobticket associated with a given print job although only
one printjobticket data object (thus the stress in the text that what was
being discussed was the datatype, something that Glen stated was
unnecessary)
Bill Wagner
From: cloud-bounces at pwg.org [mailto:cloud-bounces at pwg.org] On Behalf Of
Petrie, Glen
Sent: Wednesday, November 30, 2011 4:34 PM
To: Zehler, Peter; cloud at pwg.org
Subject: [Cloud] RE: About PWG Print Job Ticket
Peter,
Thanks for providing your model. While I understand it; from your
description, I now have an even more fundamental difference than just the
Print Job Ticket.
I would like to continue our dialog as it really helps in understand the
model that you and others are using; but, if you want to take it off the
mail list; that would be ok with me.
My fundamental difference is the role and responsibilities you discuss.
I equate your "Client" with an Application and your "Print Service" with a
"Print Client"! That is, the Application invokes a Print Client (think of
the old Print Dialog). The Print Client, along with the Print Service
capabilities (how that is obtained is another mail thread), provides the
user (or maybe the application) with a set of settable print (service,
printing) options for each document the user (or maybe the application)
wants to print as part of the Print Job. It is the Print Client that
creates the Print Job (object). The Print Client submits the Print Job to
the selected Print Service. The Print Service can then reject or acceptance
the Print Job Request. If accepted the Print Service put the Print Job in
the Print Service's print queue. I believe this what you refer to a "job
creation". In my model, only the Print Client can create Print Jobs and
only the Print Service can execute Print Jobs; it is a simple and distinct
separation of roles and responsibilities. In both the Cloud and mobile
environments, this separate enables a simpler API implementation.
While I did not discuss Print Status initially, it may or may not be
desirable to record job, print-service, printing status in the actual Print
Job Ticket; to me, that is just recording keeping and the print status could
be recorded in a number of places. To me, the questions are: Does the
Application care about print status - no. Does the Print Client care about
print status - no. Only the user care about print status. If the Print
Job fails, the User will have to invoke a new print request once the failure
has been resolved. This makes it possible (maybe desirable) for the Print
Service to send status data to a completely separate and independent Print
Status Service!! This atomic approach works well in Cloud and mobile where
the location of the individual entities can be anywhere and in different
security domains.
Back to the question of how to use your model in/with my model. For any
Print Service I create would have a binding to what I call the Print Client
or I create a Print Manager that acts as your Print Service.
glen
_____
From: Zehler, Peter [mailto:Peter.Zehler at xerox.com]
Sent: Wednesday, November 30, 2011 11:00 AM
To: Petrie, Glen; cloud at pwg.org
Subject: RE: About PWG Print Job Ticket
Glen,
I believe some of the confusion comes from the differences in various
environments on what constitutes a print job. There are many environments
that model only single document jobs. For example this is what is used in
Windows and Google Cloud Print. Other environment support multi-document
Jobs. IPP and WS-Print support multiple document jobs.
Another source of confusion seems to be where a Print Job exists. It is my
understanding that the Print Job does not exist until a job creation request
(e.g. CreateJob, PrintJob, PrintUri) is accepted by a Printer and a Job is
created based on the information in the job creation request.
I would modify your single document job model slightly
| Print Job Status
Print Job => | Print Job Content (by value or reference)
| Print Job Ticket => | Print Job Description
| Print Job
Processing
|Print Document
Processing
Where the Print Job is the job object created by the Print Service and
contains the job attributes and state
Where the Print Job Status is the set of attributes maintained by automata
for the job (e.g., JobState, ImpressionsCompleted)
Where the Print Job Content is the Document data
Where Print Job Ticket is the container element for the accepted descriptive
and processing intent
Where the Print Job Description is the Job level descriptive elements (e.g.,
JobName, DocumentFormatSupplied). (your Print Job Info and Job Content)
Where the Print Job Processing is the set of Job level processing intents
(e.g., JobPriority). (your Print Job Info)
Where the Print Document Processing is the set of attributes applied the
Print Job Content (e.g., Sides, Copies) (your Print Job Ticket).
In a single document job submission the Client supplies the Print Job
Content and optionally a Print Job Ticket in the job creation request. The
Printer copies, ignores or substitutes as appropriate when creating the
Print Job.
The multiple document job model looks like
Print Job => | Print Job Status
| Print Job Ticket => | Print Job Description
| | Print Job
Processing
| |Print Document
Processing
|Print Documents=> |Print Document=> | Print Document
Status
| Print Document Content (by value or reference)
| Print Document Ticket => | Print Document Description
|Print Document Processing
Where the Print Job is the job object created by the Print Service and
contains the job attributes and state
Where the Print Job Status is the set of attributes maintained by automata
for the job (e.g., JobState, ImpressionsCompleted)
Where Print Job Ticket is the container element for the accepted descriptive
and processing intent
Where the Print Job Description is the Job level descriptive elements (e.g.,
JobName, DocumentFormatSupplied). (your Print Job Info and Job Content)
Where the Print Job Processing is the set of Job level processing intents
(e.g., JobPriority). (your Print Job Info)
Where the Print Document Processing is the set of attributes applied the
Print Document Content (e.g., Sides, Copies) (your Print Job Ticket). (Note:
These values are used unless overridden at the document level)
Where the Print Documents is the container object created by the Print
Service for the contained Document(s)
Where the Print Document is the document object created by the Print Service
and contains the document attributes and state
Where the Print Document Status is the set of attributes maintained by
automata for the Document (e.g., DocumentState, ImpressionsCompleted)
Where the Print Document Content is the Document data
Where the Print Document Description is the Job level descriptive elements
(e.g., JobName, DocumentFormatSupplied). (your Job Content)
Where the Print Document Processing is the set of attributes applied the
Print Document Content (e.g., Sides, Copies) (your Print Job Ticket).
In a multiple document job submission the Client optionally supplies a Print
Job Ticket on the job creation request. The Print Document Content and
optionally the Print Document Ticket are supplied in the add document/uri
request. The Printer copies, ignores or substitutes as appropriate when
creating the Print Job or Print Document.
Peter Zehler
Xerox Research Center Webster
Email: Peter.Zehler at Xerox.com
Voice: (585) 265-8755
FAX: (585) 265-7441
US Mail: Peter Zehler
Xerox Corp.
800 Phillips Rd.
M/S 128-25E
Webster NY, 14580-9701
From: Petrie, Glen [mailto:glen.petrie at eitc.epson.com]
Sent: Wednesday, November 30, 2011 12:30 PM
To: cloud at pwg.org; Zehler, Peter
Subject: About PWG Print Job Ticket
Peter,
After reviewing of the later content of the Print Job Ticket specification,
I realize what is called a Print Job Ticket in the specification is what I
have always understood to mean the Print Job. And, what is called the
Document Ticket is what I have always understood to mean the Print Job
Ticket. For example, in JTAPI, the attribute in the specification that are
associated with the Document Ticket are those associated in JTAPI with a
Print Job Ticket.
Perhaps you can provide me a reference for a Print Job.
My understanding is that a Client submits a Print Job to a Print Service. A
Print Job consists of a Print Job Ticket and Print Job Content (Document)
and Print Job Info (parts of what you call PrintJobDescription and
PrintJobProcessing).
My model
| Print Job Info
Print Job => | Print Job Ticket
| Print Job Content
Where the Print Job Info is the set of attributes you have that start with
'Job'.
Where the Print Job Ticket is the set of attributes applied the Print Job
Content; what you call DocumentTicket/Processing.
Where the Print Job Content is the set of "documents" and attributes that
you generally have that start with 'Document'
In the specification the model is sort of like mine but the 'labels' are
different and some elements/attributes moved around. The closet analog is
| Print Job Processing
Print Job Ticket => | Print Document Processing (could be Print Document
Ticket)
| Print Job Description
Since the PWG:PJT models, object and attributes are, I assume, based on
IPP-isms and naming conventions; I believe the best solution is mapping of
the PWG:PJT in binding code for support of the PWG:PJT.
So, I retracted my comments made yesterday and I will focus on bindings
and/or mappings of the PWG:PJT.
Glen
--
This message has been scanned for viruses and
dangerous content by <http://www.mailscanner.info/> MailScanner, and is
believed to be clean.
--
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/20111130/8f704de9/attachment-0002.html>