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 at cp10.es To: sm at pwg.org, Dennis Carney/Boulder/IBM at IBMUS
.xerox.com> cc: ipp at 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