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 04 2002 - 00:26:27 EDT

  • Next message: Zehler, Peter: "SM> Thursday Semantic Model telecon info"

    Ira, you are absolutely right about the prolific output of the
    "non-group". My concern is... with so much work emanating... SHOULD we be
    meeting at the f2f!? It seems these topics have been discussed mostly in
    the SM or Plenary sessions.

    I think the use of attributes for "-actual" (or -chosen if that's what we
    decide) was accepted in today's SM conference call. Dennis and I will be
    working on a PWG draft. In my opinion. if we go so far as to add
    operations than the operation should facilitate a full job-ticket/receipt
    like JDF or whatever else we come up with in that regard.
    ----------------------------------------------
    Harry Lewis
    IBM Printing Systems
    ----------------------------------------------

    "McDonald, Ira" <imcdonald@sharplabs.com>
    Sent by: owner-sm@pwg.org
    10/03/2002 08:55 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
            Subject: RE: SM> Job "Actual" attributes

     

    Hi,

    I'm in favor of the actual attributes, WITHOUT any new operations,
    as either "chosen" or "actual". IPP, Novell NDPS, ISO DPA, and a
    whole lot of vendor proprietary DPA-based protocols have supported
    the multiple attribute tuple "base, base-default, base-supported"
    for years. Many of those also supported "base-requested" and
    "base-chosen" for the exact reason Harry has raised.

    Cheers,
    - Ira McDonald
      High North Inc

    PS - The non-existent PWG IPP WG that Harry and Pete alluded to
    has already produced 4 IEEE/ISTO standards. For the Distributed
    Notifications and the IPPGET offloading via redirect, Tom Hastings
    and I are working with Harry Lewis and Bob Herriot right now to
    write two more. I contend that we should simply never use the
    second, PWG unique, IPP mailing list. We need to IANA register
    ALL of the IPP extension attributes and their values. The PWG
    does NOT maintain the authoritative registry of IPP attributes.
    Through Tom's good work with Michelle at IANA, IANA _will_ do
    that registry. Oh and three more IETF IPP docs that are stalled
    are already slated to be reissued as PWG IPP docs (INDP and
    mailto Notifications and Driver Install). That's a lot of specs
    for a non-existent PWG IPP WG...

    -----Original Message-----
    From: Harry Lewis [mailto:harryl@us.ibm.com]
    Sent: Thursday, October 03, 2002 12:37 PM
    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 04 2002 - 00:29:38 EDT