Peter, here is very simplified model from my perspective. No enough
time to add more details. But I can explain it and get your comments.
Glen
________________________________
From: cloud-bounces at pwg.org [mailto:cloud-bounces at pwg.org] On Behalf Of
Petrie, Glen
Sent: Thursday, December 01, 2011 6:45 AM
To: Zehler, Peter; cloud at pwg.org
Subject: RE: [Cloud] RE: About PWG Print Job Ticket
Ok, let have the meeting.
Glen
________________________________
From: Zehler, Peter [mailto:Peter.Zehler at xerox.com]
Sent: Thursday, December 01, 2011 6:42 AM
To: Petrie, Glen; cloud at pwg.org
Subject: RE: [Cloud] RE: About PWG Print Job Ticket
Glen,
I was planning on using diagrams from <
http://www.linuxfoundation.org/sites/main/files/JTAPI.GSOC_.201104.06.pd
f> and XMLSPY for the PWG model as well as simple drawings using a tool
such as Visio created real time. (If you know of other pictures lying
around we can use those as well.) Isn't it possible to throw something
together that we can talk to this afternoon? My work time for the
remainder of the year is quite limited and beginning the new calendar
year I'll be loaded down with work in a new research area. I would
think a discussion might help you in your CPDC work as well as helping
me with the PWG Job Ticket spec.
Can we discuss it today...or at least begin a discussion?
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
From: Petrie, Glen [mailto:glen.petrie at eitc.epson.com]
Sent: Thursday, December 01, 2011 9:19 AM
To: Zehler, Peter; cloud at pwg.org
Subject: RE: [Cloud] RE: About PWG Print Job Ticket
Peter,
JTAPI aside, I believe we have a different overall print model; which
reduce the situation to a matter of mapping and bindings. I am working
on the Common Mobile Print Dialog (Client) (CPDC) for OpenPrinting and
would like to use the PWG:PJT. I realize the PWG activities are not
specifically concerned with specifying is part of the print chain but I
am trying to make the two mesh together. I am doing a write up for
OpenPrinting now and will copy you if you are interested.
Since this type of discussion really take diagrams along with
discussion; let me do the write up before we talk.
Glen
________________________________
From: cloud-bounces at pwg.org [mailto:cloud-bounces at pwg.org]
<mailto:%5bmailto:cloud-bounces at pwg.org%5d> On Behalf Of Zehler, Peter
Sent: Thursday, December 01, 2011 4:07 AM
To: William Wagner; cloud at pwg.org
Subject: RE: [Cloud] RE: About PWG Print Job Ticket
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=atten
d&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]
<mailto:%5bmailto:cloud-bounces at pwg.org%5d> 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]
<mailto:%5bmailto:cloud-bounces at pwg.org%5d> 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]
<mailto:%5bmailto:Peter.Zehler at xerox.com%5d>
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]
<mailto:%5bmailto:glen.petrie at eitc.epson.com%5d>
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.
--
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, and is
believed to be clean.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.pwg.org/pipermail/cloud/attachments/20111201/fa9e2ed2/attachment-0002.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: simplifed CMPC.pdf
Type: application/octet-stream
Size: 175869 bytes
Desc: simplifed CMPC.pdf
URL: <http://www.pwg.org/pipermail/cloud/attachments/20111201/fa9e2ed2/attachment.obj>