Semantic Model Mail Archive: RE: SM> ACT - IPP "-actual

Semantic Model Mail Archive: RE: SM> ACT - IPP "-actual

RE: SM> ACT - IPP "-actual" attributes downloaded, version 0.1 [m y comments]

From: Dennis Carney (dcarney@us.ibm.com)
Date: Thu Oct 31 2002 - 19:04:05 EST

  • Next message: ElliottBradshaw@oaktech.com: "Re: SM> ACT - Summary of today's discussion of the "-actual" proposal"

    Tom,

    Thanks for bringing these up. In response to your 4 points:

    1. I believe the "-actual" concept should be extended to Document Template
    attributes. This means that for every Document Template attribute, there
    is a corresponding "-actual" Document Description attribute that reports on
    the actual value of that attribute for that document. The question of
    which "-actual" attributes are Job Description attributes and which are
    Document Description attributes, then, is answered in the Document Object
    spec, in Table 6 (Draft 0.4). Of course, if we go with this proposal, I
    need to make the extension of the concept to the Document Template
    attributes clear in the "-actual" attributes document.

    2. We came to a conclusion, I believe, on this in the teleconference today.
    We decided that any design for how to make the actual value of the
    "document-format" attribute available to the client would be discussed in
    the Document Object spec. There will be no "document-format-actual"
    attribute in the "-actual" attributes spec.

    3. I tried to cover this topic in section 3.2, which reads:
       3.2 Relationship between "-actual" attributes and Job Template
       attributes

       A very important point about the new "-actual" attributes is that
       support for them is not in any way tied to the support for the
       corresponding Job Template attributes. For example, a Printer that does
       not support PDL override will not support the "copies" Job Template
       attribute either. However, that same Printer SHOULD support the
       "copies-actual" attribute if the Printer knows how many copies printed
       for a job.
       Similarly, the "-actual" attribute's existence is not in any way tied to
       the existence of the Job Template attribute on the job creation request.
       Whether or not a number of copies was requested, the Printer SHOULD
       report on how many copies actually printed if the value is known.
    Does this satisfy you?

    4. I believe Printers should fill in the values as soon as they have some
    strong confidence they know them. I do not believe that in general, the "
    -default" attributes necessarily have a strong shot at being right. I feel
    strongly that we should not make any rules except to say that the Printer
    should not return a value unless it thinks that value is correct--this is
    not a guarantee of correctness, but a guarantee that the Printer honestly
    *thinks* it is correct. I know that if we went with your proposal, if I
    wrote a monitoring app, I would be hesitant to use the value, since it
    would too often result in me giving bad information to the user.
    By the way, counting on 'pending' or 'pending-held' being the only states
    where information is not "final" is wrong. Once a job starts processing,
    it might take significant time before the Printer determines a final value.
    I don't believe that an "-actual" value can be considered final until the
    job enters a completion state (completed, canceled, or aborted), as I say
    in section 3.1.

    Dennis

                                                                                                                                                       
                          "Hastings, Tom N"
                          <hastings@cp10.es To: sm@pwg.org, Dennis Carney/Boulder/IBM@IBMUS
                          .xerox.com> cc: ipp@pwg.org
                                                   Subject: RE: SM> ACT - IPP "-actual" attributes downloaded, version 0.1 [m y comments]
                          10/31/02 10:59 AM
                                                                                                                                                       
                                                                                                                                                       

    Dennis,

    Good concept and good writeup.

    I have a few detailed issues/suggestions:

    1. Interaction with Document objects

    Another reason for more than one value at the job level might be that
    different documents have different values.

    On the other hand, for the Document object, won't we want to have -actual
    for the Document Description attributes too? If so, which -actual
    attributes would be Job Description attributes and which would be Document
    Description? media-actual would be a Document Description attribute and
    job-priority-actual would be a Job Description attribute.

    2. Even though "document-format" isn't a Job Template (or a Document
    Template) attribute, I think that for a file sniffing Printer, having a
    "document-format-actual" (which has to be multi-valued since a
    multi-document job could be sniffed to different values).

    And for the Document object it would be a Document Description attribute.

    3. A printer that doesn't support a Job Template attribute, say,
    resolution,
    but does in the PDL, could have a resolution-actual attribute, right? This
    case needs to be indicated.

    4. ISSUE: If a job is submitted with none or few Job Templates supplied,
    does the Printer fill in the remaining -actual with its default value?
    When? Can it supply the default values for these immediately, before it
    has
    processed the PDL? And then change the value if the PDL has a
    specification
    for that attribute? I suggest yes, and then clients know that -actual
    values when the job is 'pending' or 'pending-held' are subject to change.

    Tom



    This archive was generated by hypermail 2b29 : Thu Oct 31 2002 - 19:05:33 EST