SM> Job "Actual" attributes

SM> Job "Actual" attributes

Harry Lewis harryl at
Fri Oct 11 01:11:00 EDT 2002

We would prefer a job ticket approach (and have been lobbying for one in 
the PWG Semantic Model, including a submission for a simple way for IPP to 
carry a job ticket and the recommendation that we consider a simplified 
JDF JT as the basis... thereby leveraging expended effort). So I support 
Bob Taylor's recommendations, in general, and discussions regarding 
optimization. Several comments, however.

1. Our proposal to add "-actual" (to the existing cadra of IPP 
"-supported", "-default", "-ready", "-requested" etc. attributes) is 
intended as a SIMPLE solution which could be supported in v1 of the 
Semantic Model and PSI.
2. At today's SM conference call we said we will NOT try and define a Job 
Ticket for v1 (wise decision, as I'm sure we've barely begun to imagine 
all the nuances of JT and got stuck, almost immediately on the question of 
Job vs Doc JTs).
3. Assuming it will take a while for us to hash out the ideal JT for 
office applications I would like to see us go forward with the rather 
benign "-actual" proposal
4. Back on the JT thread... I do NOT like the streamlining proposed 
(below) by Tom. Specifically, if we limit Job Processing Actuals to only 
ones deferred from attributes declared during job creation, we will MISS 
information if, for example, the PDL had embedded commands that resulted 
in an action that was not requested. (ex. Job creation was silent on 
copies, the PDL called for 3 copies). Our view is we WANT to know exactly 
what HAPPENED... (we care less why). 
Harry Lewis 
IBM Printing Systems 

"Hastings, Tom N" <hastings at>
Sent by: owner-sm at
10/10/2002 05:38 PM
        To:     Harry Lewis/Boulder/IBM at IBMUS, "TAYLOR,BOB 
(HP-Vancouver,ex1)" <robert_b_taylor at>
        cc:     "McDonald, Ira" <imcdonald at>, "Zehler, Peter" 
<PZehler at>, sm at, printing-jobticket at
        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
The FSG Job Ticket API wants to store results in the Job Ticket eventually 
as well.
-----Original Message-----
From: Harry Lewis [mailto:harryl at]
Sent: Thursday, October 03, 2002 09:37
To: TAYLOR,BOB (HP-Vancouver,ex1)
Cc: McDonald, Ira; Zehler, Peter; sm at
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 at> 
10/03/2002 09:42 AM 
        To:        "Zehler, Peter" <PZehler at>, Harry 
Lewis/Boulder/IBM at IBMUS, "McDonald, Ira" <imcdonald at>, 
sm at 
        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 
-----Original Message-----
From: Zehler, Peter [mailto:PZehler at]
Sent: Thursday, October 03, 2002 4:43 AM
To: 'Harry Lewis'; McDonald, Ira
Cc: sm at
Subject: RE: SM> Job "Actual" attributes

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. 
Peter Zehler 
Xerox Architecture Center 
Email: PZehler at 
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 at]
Sent: Wednesday, October 02, 2002 11:57 PM
To: McDonald, Ira
Cc: sm at
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 at> 
10/02/2002 07:30 PM 
       To:        Harry Lewis/Boulder/IBM at IBMUS, sm at 
       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).

- Ira McDonald

-----Original Message-----
From: Harry Lewis [mailto:harryl at]
Sent: Wednesday, October 02, 2002 5:56 PM
To: sm at
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. 
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 
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 
(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 
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 

-------------- next part --------------
An HTML attachment was scrubbed...

More information about the Sm mailing list