Semantic Model Mail Archive: RE: SM> Job "Actual"

Semantic Model Mail Archive: RE: SM> Job "Actual"

RE: SM> Job "Actual" attributes

From: Harry Lewis (harryl@us.ibm.com)
Date: Fri Oct 11 2002 - 01:11:00 EDT

  • Next message: Harry Lewis: "RE: [printing-jobticket] RE: SM> Job "Actual" attributes"

    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@cp10.es.xerox.com>
    Sent by: owner-sm@pwg.org
    10/10/2002 05:38 PM
     
            To: Harry Lewis/Boulder/IBM@IBMUS, "TAYLOR,BOB
    (HP-Vancouver,ex1)" <robert_b_taylor@hp.com>
            cc: "McDonald, Ira" <imcdonald@sharplabs.com>, "Zehler, Peter"
    <PZehler@crt.xerox.com>, 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 : Fri Oct 11 2002 - 01:16:28 EDT