Semantic Model Mail Archive: RE: [printing-jobticket] RE: SM&gt

Semantic Model Mail Archive: RE: [printing-jobticket] RE: SM>

RE: [printing-jobticket] RE: SM> Job "Actual" attributes

From: Zehler, Peter (
Date: Tue Oct 15 2002 - 07:06:04 EDT

  • Next message: Zehler, Peter: "SM> Semantic Model Telecon Agenda"

    Comments below.

                                    Peter Zehler
                                    Xerox Architecture Center
                                    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: PRATT,SHAWN (HP-Boise,ex1) []
    Sent: Friday, October 11, 2002 11:28 AM
    To: TAYLOR,BOB (HP-Vancouver,ex1); 'Hastings, Tom N'; Harry Lewis
    Cc: McDonald, Ira; Zehler, Peter;;
    Subject: RE: [printing-jobticket] RE: SM> Job "Actual" attributes

    So in reading all of this as well as undertanding the work going on in
    OpenPrinting, I have a general questions that may be obvious to others but
    not to me yet. The assumed communication link for this work has been IPP.

    IPP allows for:
            a) Query printer capabilities,
            b) Submit print jobs,
            c) Inquire about the status of print jobs and printers,
            d) Cancel print jobs.
            e) Runs on top of HTTP 1.1.

    IPP does not currently allow for:
            a) Support for scan or fax. There is an active effort (PWG-IFX)
              to use IPP for Internet fax, though it's incomplete right now.
                You could probably fake fax through IPP, but I don't know if
              anybody has done it. Scan definitely isn't supported.
    <PZ> Yes IPP is print specific. The PWG is addressing fax. Other
    based on IPP semantics (i.e. UPnP) are addressing multifunction devices and
    scanning. There may be interest in expanding the PWG charter to model these
    devices along with printers and print services. </PZ>
            b) Does not support Job tickets. I know a lot of these discussion
              is about determined what to do for IPP to support job tickets.
              We need to determine this in our work as well as see what is
              being done elsewhere.
    <PZ> This is dependent on your point of view and definition of a Job Ticket.
    If you define a Job Ticket as production instructions to be applied to a
    print job then IPP already has Job Template attributes that act as a Job
    If your definition of a Job ticket involves the sequencing of processes that
    constitute a job, the routing of the job through a system, and a receipt for
    work performed on a job, then IPP is not what is needed. (We have JDF to
    Prepress, Press and Post-Press Processing) IPP is focused on Client to
    Service printing. The Client may take many forms from command line
    interfaces to
    "adapters" on the back end of work flow systems. The Print Server may take
    forms from a doggle that hangs off a print devices parallel port to a print
    on a mainframe.
    In the PWG Semantic work we are grouping the attributes into description and

    processing elements that provide the building blocks for a Print Job Ticket.
            c) The format of printer capabilities is all done with
              independently defined attributes - you query individually by
              attribute. They are vendor extensible, but you need to
              register them through IANA.
    <PZ> Yes the attributes in the IPP are independent. That is not
    with a capabilities mechanism. The PWG Semantic model is intended to
    collect the
    industry wide agreed upon semantic elements. These semantic elements may
    be used in a variety of print related efforts including a capability query
    mechanism. A capability mechanism can easily be added to IPP.
    IPP and the Semantic Model allows for vendor and site extensions to the
    We have a small number of attributes (i.e. type 1) that must receive an IANA

    registration. Things like Job state should have a well defined set of
    and transitions. Other attributes (i.e. type 2) require only registration
    with the
    PWG. There are also attributes (i.e. type 3) that require no registration.
    In practice only a couple of attributes are not extensible. </PZ>
            d) IPP has the concept of an intent ticket, but it is not XML
              based, and not easily extensible.
    <PZ> I could not disagree more. Implementation experience has demonstrated
    extensibility. Extensibility achieved without sacrificing interoperability.
    have simple implementations in doggles smaller than a cigarette pack that
    sit next to an IPP server in a mainframe. An IPP Client is able to
    with both and if properly designed can make use of the capabilities of the
    based IPP Printer and still accomplish printing with the doggle based IPP
            e) The model is also primarily enterprise oriented. What would
              need to be done to support the consumer space.
    <PZ> The model has demonstrated its ability to scale from consumer devices
    to enterprise systems </PZ>

    Am I correct in these observations?
    <PZ> I don't believe so. I have data from three interoperability tests
    to back me up. </PZ>

    For the Linux standard print model work that the FSG OpenPrinting WG is
    doing, our goals are not to "reinvent the wheel" and not simply patch the
    current solutions. Our objectives are to work with the standards working
    groups that are already working on various parts of the print model puzzle
    to ensure that said standards work well for the Linux environment. In order
    to do this correctly, first, we need to define the basic print path and the
    components/standards used along that path. Second, we need to identify what
    is missing from those components and standards. Finally, we need to be
    working with those owners to make the improvements and/or implementing Linux
    specific APIs/components. As well, the OpenPrinting WG is also about
    looking forward. Questions we need to answer are: What is the print model
    solution we would like for the future? How can we best provide an
    architecture and solution that:
            a) Is scalable to allow solution providers (print vendors,
              distributors, and even users) ensure a basic print model,
              but also build on it easily to extend the model is the
              direction suited for their business.
            b) Makes it easy for a print vendor to have a solution for
              their product. What I mean here is at a basic print
              model level, the vendor does not have to apply many, if
              any, resourses to supporting their product. They can
              then focus on the extensibility for their products if
              required for their business model needs.
            c) Is consistent for end-users so they get a consistent print
              experience across the different distributions they may be

    For IPP, I am wondering if we have chosen the correct communication link. I
    know this has been the standard used in Linux for sometime, but it seems to
    be missing some pretty major parts that we would need. As well, there are
    other standards being developed such as UPnP and PSI that seem to be working
    in this same space and seem to be already addressing those needs.

    <PZ> It seems to me that IPP has demonstrated its ability to accommodate
    your three items above. I would prefer to leverage existing standards.

    I am not trying to create headaches for everyone. I just want to make sure
    we are looking at all of our options.


    Shawn Pratt
    Client Software for Device Enablement and Usage
    11311 Chinden Blvd., MS 235, Boise, ID 83714
    Phone: 208-396-4628
    -----Original Message-----
    From: TAYLOR,BOB (HP-Vancouver,ex1) []
    Sent: Thursday, October 10, 2002 5:55 PM
    To: 'Hastings, Tom N'; Harry Lewis
    Cc: McDonald, Ira; Zehler, Peter;;
    Subject: [printing-jobticket] RE: SM> Job "Actual" attributes

    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"?>
        <mediaSize>A4 </mediaSize>
        <logging timestamp="10/10/2002 4:50pm PDT" logger=>
            <mediaSize>US_Letter</mediaSize> <!-- service didn't have A4, so it
    substituted US Letter -->
    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.
    -----Original Message-----
    From: Hastings, Tom N []
    Sent: Thursday, October 10, 2002 4:38 PM
    To: Harry Lewis; TAYLOR,BOB (HP-Vancouver,ex1)
    Cc: McDonald, Ira; Zehler, Peter;;
    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

    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 []
    Sent: Thursday, October 03, 2002 09:37
    To: TAYLOR,BOB (HP-Vancouver,ex1)
    Cc: McDonald, Ira; Zehler, Peter;
    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)" <>
    10/03/2002 09:42 AM
            To: "Zehler, Peter" <>, Harry
    Lewis/Boulder/IBM@IBMUS, "McDonald, Ira" <>,
            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 []
    Sent: Thursday, October 03, 2002 4:43 AM
    To: 'Harry Lewis'; McDonald, Ira
    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
    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 []
    Sent: Wednesday, October 02, 2002 11:57 PM
    To: McDonald, Ira
    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" <>
    10/02/2002 07:30 PM
           To: Harry Lewis/Boulder/IBM@IBMUS,
           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 []
    Sent: Wednesday, October 02, 2002 5:56 PM
    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

    printing-jobticket mailing list

    This archive was generated by hypermail 2b29 : Tue Oct 15 2002 - 07:06:22 EDT