Hi Glen,
The SM call time is 12pm Pacific / 3pm Eastern (i.e., *after* our
upcoming PWG SC meeting at 2pm Eastern).
I'll call in then.
Cheers,
- Ira
On Thu, Dec 1, 2011 at 1:11 PM, Petrie, Glen <glen.petrie at eitc.epson.com>wrote:
> ** ** ** ** **
>> Waited 10 min but no one else on the call. If you decide to convene the
> meeting, please send me a mail note.****
>> ** **
>> 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.pdf>
> 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] *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=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. ****
>>> --
> 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.org>https://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/cloud/attachments/20111201/f57248c4/attachment-0002.html>