---------- Forwarded message ----------
From: Zehler, Peter <Peter.Zehler at xerox.com>
Date: Thu, Dec 1, 2011 at 7:06 AM
Subject: RE: [Cloud] RE: About PWG Print Job Ticket
To: William Wagner <wamwagner at comcast.net>, cloud at pwg.org
Glen, Bill and any interested parties,****
** **
I just don’t type well enough to discuss a matter like this in enough
detail. It is also a discussion that would work better in real time. I
propose we use today’s SM Teleconference slot (phone and LiveMeeting info
below) to discuss this productively.****
** **
The short answer Glen is that the JTAPI Job maps to a PWG PrintJob
operation in a single document job. It maps to a CreateJob,
1*AddDocument/Uri, CloseJob operations in a multiple document Job. The Job
in your model closely aligns with a JobTicket in the PWG with the exception
that documents(Run Lists in JDF) are not contained in a JobTicket. It
should also be noted that the PWG model does not explicitly model a
JobDocumentPage though we do have PageOverrides.****
** **
Pete****
** **
** **
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 ****
** **
Agenda: Thursday December 1, 3pm EST****
****
** **
1. Identify Minute Taker****
****
2. Job Ticket mapping of PWG/JTAPI/JDF ****
****
** **
****
*Audio Information *
Call-in toll-free number (US/Canada): 1-866-469-3239 ****
** **
Call-in toll number (US/Canada): 1-650-429-3300 ****
** **
Call-in toll number (US/Canada): 1-408-856-9570 ****
** **
Attendee access code: (by request only, please contact me if you do not
have it).****
** **
*LiveMeeting URL:*****
** **
*<
https://www.livemeeting.com/cc/xerox/join?id=PwgSemanticModel&role=attend&pw=LetMeIn
> ***
* *****
** **
*LiveMeeting First Time Users: *
To save time before the meeting, check your system
<http://go.microsoft.com/fwlink/?LinkId=90703>to make sure it is ready to
use Microsoft Office Live Meeting. ****
** **
*LiveMeeting Troubleshooting*
Unable to join the meeting? Follow these steps: ****
** **
**1. **Copy this address and paste it into your web browser:
https://www.livemeeting.com/cc/xerox/join ****
**2. **Copy and paste the required information:
Meeting ID: PwgSemanticModel
Entry Code: LetMeIn
Location: https://www.livemeeting.com/cc/xerox ****
** **
** **
** **
*From:* cloud-bounces at pwg.org [mailto:cloud-bounces at pwg.org] *On
Behalf Of *William
Wagner
*Sent:* Wednesday, November 30, 2011 8:15 PM
*To:* cloud at pwg.org
*Subject:* RE: [Cloud] RE: About PWG Print Job Ticket****
** **
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 *MailScanner* <http://www.mailscanner.info/>, and is
believed to be clean. ****
--
This message has been scanned for viruses and
dangerous content by *MailScanner* <http://www.mailscanner.info/>, and is
believed to be clean. ****
--
This message has been scanned for viruses and
dangerous content by *MailScanner* <http://www.mailscanner.info/>, and is
believed to be clean.
_______________________________________________
cloud mailing list
cloud at pwg.orghttps://www.pwg.org/mailman/listinfo/cloud
--
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/mfd/attachments/20111201/c254284f/attachment-0002.html>