Since Tom brought up the idea of storing results in the job ticket, we've
been thinking of this as "logging annotations" - i.e., you push these
"actuals" as logging elements that are added to the ticket as it's
processed. This would look something like:
<?xml version="1.0" encoding="UTF-8"?>
<ticket>
<mediaSize>A4 </mediaSize>
<logging timestamp="10/10/2002 4:50pm PDT" logger=252.15.43.255>
<mediaSize>US_Letter</mediaSize> <!-- service didn't have A4, so it
substituted US Letter -->
</logging>
</ticket>
With this, you don't have to redefine elements, even if the service changed
them (the "actual" is implied by the <logging/> structure), and you can
attach other attributes to the log timestamps, logger IDs, etc. You have
both the original intent and the logging information in the same ticket for
archival/audit/accounting, but it's simple to strip all the logging out and
re-use the ticket if you want to.
thoughts?
bt
-----Original Message-----
From: Hastings, Tom N [mailto:hastings@cp10.es.xerox.com]
Sent: Thursday, October 10, 2002 4:38 PM
To: Harry Lewis; TAYLOR,BOB (HP-Vancouver,ex1)
Cc: McDonald, Ira; Zehler, Peter; sm@pwg.org;
printing-jobticket@freestandards.org
Subject: RE: SM> Job "Actual" attributes
I like Bob Taylor's idea of using the same PWG Semantic Model Job and
Document Processing attributes (probably not PWG SM Description attributes)
in a different context to indicate what really happened, rather than
inventing more xxx-actual attributes. The PWG Semantic Model already uses
this approach for Job Creation, in that Document Processing attributes can
be supplied at the Job Level in the Create-Job operation and in each
Send-Document operation. The IPP Document object extension proposes
re-using the same IPP Job Template attributes as Document Template
attributes, rather than inventing new "document-xxx" Document Template
attributes. (Also the IPP "document-overrides" and "page-overrides"
collection attributes re-use the existing Job Template attributes for each
override collection value, rather than inventing new name mangling for
them).
However, I'd also like to suggest a streamlining, by having the new Job
Processing Actuals be only the ones that deferred from the ones submitted in
the Job Creation Request. This would do two good things: Be much more
compact and provide a useful indication to the user about what happened
differently from what he requested. I suspect that any defaulting that the
Printer supplied would wind up in the Actuals group, but be of the form
"xxx", not "xxx-default". If the PDL had a different value and the Printer
didn't override the PDL, then the actual should be the value from the PDL.
Of course, the Job Processing, Job Description, Document Processing, and
Document Description attributes that the user submitted should also be in
the Job History in just the form that he submitted (as in the current IPP
Job History for Job Template attributes and soon to be Document Template
attributes - see RFC 2911 section 4.3.7.2).
The FSG Job Ticket API wants to store results in the Job Ticket eventually
as well.
Comments?
Tom
-----Original Message-----
From: Harry Lewis [mailto:harryl@us.ibm.com]
Sent: Thursday, October 03, 2002 09:37
To: TAYLOR,BOB (HP-Vancouver,ex1)
Cc: McDonald, Ira; Zehler, Peter; sm@pwg.org
Subject: RE: SM> Job "Actual" attributes
I'm not opposed to new operations but I'll observe that multiple attributes
is in keeping with the way IPP is currently structured.
----------------------------------------------
Harry Lewis
IBM Printing Systems
----------------------------------------------
"TAYLOR,BOB (HP-Vancouver,ex1)" <robert_b_taylor@hp.com>
10/03/2002 09:42 AM
To: "Zehler, Peter" <PZehler@crt.xerox.com>, Harry
Lewis/Boulder/IBM@IBMUS, "McDonald, Ira" <imcdonald@sharplabs.com>,
sm@pwg.org
cc:
Subject: RE: SM> Job "Actual" attributes
I think I prefer the more "operations" or structurally-oriented approach.
The model of having multiple attributes that describe the same "feature" in
multiple states (capabilities, intent, process, logging/audit), etc. seems
fragile and error-prone (hence the current "process" vs. "product"
discrepancies in CIP4 ...). I'd rather have us define the feature once, and
then define operations or structures that apply the workflow stage
semantics.
bt
-----Original Message-----
From: Zehler, Peter [mailto:PZehler@crt.xerox.com]
Sent: Thursday, October 03, 2002 4:43 AM
To: 'Harry Lewis'; McDonald, Ira
Cc: sm@pwg.org
Subject: RE: SM> Job "Actual" attributes
Harry,
I like the concept. I prefer "actual" to "chosen". Have you considered new
operations (e.g. "GetActualJobAttributes" "GetJobsHistory") to accomplish
the same thing. It would make Printers that implement a job receipt more
explicit. There would be no need for all the new attributes (i.e.
"ZZZ-actual"). On the other hand using attributes instead of new operations
does have the benefit of being able to retrieve both the requested and
actual attributes together and having a static representation that
differentiates the two. Perhaps using both the "actual" attributes and new
operations might be more explicit.
Of course there will probably need to be some housekeeping attributes added
to the printer for history management/configuration. I would prefer that
something like this be documented separately and referenced in the PWG
Semantic Model. The document would probably be an extension to IPP.
Pete
Peter Zehler
XEROX
Xerox Architecture Center
Email: PZehler@crt.xerox.com
Voice: (585) 265-8755
FAX: (585) 265-8871
US Mail: Peter Zehler
Xerox Corp.
800 Phillips Rd.
M/S 128-30E
Webster NY, 14580-9701
-----Original Message-----
From: Harry Lewis [mailto:harryl@us.ibm.com]
Sent: Wednesday, October 02, 2002 11:57 PM
To: McDonald, Ira
Cc: sm@pwg.org
Subject: RE: SM> Job "Actual" attributes
I'm fine with "chosen" vs. "actual"... not as concerned about the name as
the concept. In this case, actual might differ from requested due to
something like a PDL override (so "chosen" seems to fit) or it COULD differ
due to some circumstance (like the job was aborted prior to all copies
completing) in which case "actual" seems more apropos.
----------------------------------------------
Harry Lewis
IBM Printing Systems
----------------------------------------------
"McDonald, Ira" <imcdonald@sharplabs.com>
10/02/2002 07:30 PM
To: Harry Lewis/Boulder/IBM@IBMUS, sm@pwg.org
cc:
Subject: RE: SM> Job "Actual" attributes
Hi Harry,
For what it's worth...
Printer MIB used (from DPA I think...) the terminology of
'Declared' or 'Requested' (for the input) and 'Chosen'
(for what you're calling 'Actual' below).
Cheers,
- Ira McDonald
-----Original Message-----
From: Harry Lewis [mailto:harryl@us.ibm.com]
Sent: Wednesday, October 02, 2002 5:56 PM
To: sm@pwg.org
Subject: SM> Job "Actual" attributes
In IPP, PWG Semantic Model and PSI we have Job Template attributes with
"sister" (supported, default and ready) Printer Description attributes. When
discussing the purpose of a "Job Ticket" in the semantic model, we often
refer to Job Template attributes as the "job ticket" as these carry
production intent. By definition, when queried, Job Template attributes must
return the value associated with each attribute during submission. Thus,
there is no way to query a job (or document) and learn WHAT ACTUALLY
HAPPENED w.r.t. any particular attributed (ex. copies). This is covered by
the JDF job ticket but we have said JDF is too workflow oriented for
(initial) inclusion into the PWG Semantic Model.
I would like to propose a solution - the addition of a group of Job
Description attributes referred to as "-actual". These could be extensions
to the group of Job Progress attributes or a separate grouping of Job Actual
(or "Job Completion") attributes. I know, in IPP proper, we don't have the
notion of job "history" (the job "disappears" as soon as it has completed)
so "actuals" would not be very useful. But in the semantic model and PSI
we're trying to overcome this. To the extent that we are reluctant to
embrace a full fledged job ticket, the addition of "-actual" attributes
should go a long way toward providing much of the essential JT functionality
that was previously missing for non-produciton environments.
For example:
+===================+======================+
| Job Template |Job Description:Actual|
| Attribute | Value Attribute |
+===================+======================+
| copies | copies-actual |
| (integer (1:MAX)) | (integer (1:MAX)) |
+-------------------+----------------------+
| finishings | finishings-actual |
|(1setOf type2 enum)|(1setOf type2 enum) |
+-------------------+----------------------+
| sides | sides-actual |
| (type2 keyword) | (type2 keyword) |
+-------------------+----------------------+
| number-up | number-up-actual |
| (integer (1:MAX)) | (integer (1:MAX)) |
+-------------------+----------------------+
| orientation- |orientation-requested-|
| requested | actual |
| (type2 enum) | (type2 enum) |
+-------------------+----------------------+
| media | media-actual |
| (type3 keyword | | (type3 keyword | |
| name) | name) |
+-------------------+----------------------+
| printer-resolution| printer-resolution- |
| (resolution) | actual |
| | (resolution) |
+-------------------+----------------------+
| print-quality | print-quality-actual |
| (type2 enum) | (type2 enum) |
+-------------------+----------------------+
----------------------------------------------
Harry Lewis
IBM Printing Systems
----------------------------------------------
This archive was generated by hypermail 2b29 : Thu Oct 10 2002 - 19:54:50 EDT