As we add more attributes to the document level, we are making
validation more difficult. With document level attributes it is
possible for CreateJob to succeed and for a later SendDocument to
fail because of an unsupported attribute. Thus the success of
CreateJob is no longer an indicator of success and ValidateJob isn't
either because it assumes that all attributes are job level.
An attribute supported at the job level may fail at the document
level.
So I ask, are we starting down another slippery slope that should
best wait for some version after IPP Version 1.0? When we just
had document-format, we could mandate that it must be the same for
all documents, as required by some print systems. We could do the
same for compression. But now with document-k-octets, and additional
proposed attributes, things are getting more difficult.
The real issue is whether ALL attributes, even document ones, should be
in the PrintJob/CreateJob operation so that a job can be fully
validated during the initial operation, or should document level
attributes be in the SendDocument operation where it may be more
convenient to send them. There are pros and cons. I think that we may
find it hard to make an irrevocable commitment at this late hour.
Bob Herriot
> From hastings at cp10.es.xerox.com Wed Sep 10 07:58:34 1997
>> Subj: Simple proposal to allow more Job Template attributes to be per-document
> From: Tom Hastings
> File: per-doc.doc
> Date: 9/9/97
>> The latest draft Model document OPTIONALLY allows 5 job template attributes
> to be document attributes when Create-Job/Send-Document and Send-URI
> operations are implemented:
>> document-format
> compression
> document-k-octets
> document-impressions
> document-media-sheets
>> as agreed in Redmond.
>> See the table in section 4.2 and the list in section 4.4.
>> The table in section 4.2 is divided into two parts, with the above 5
> attributes being last in the table.
>>> I talked with Roger yesterday and we'd like to make the following proposal:
>>> 1. We'd like to move the boundary up to include the attributes from "media"
> down through "page-range" as well. Thus the following job template
> attributes would become optional document attributes along with the above 5:
> "media", "number-up", "sides", "printer-resolution", "print-quality" and
> "page-range".
>> The "finishing" and "copies" attributes already have the
> "multiple-document-handling attribute to control their semantics, so maybe
> they should remain as job level only. Then move them up next to
> "multiple-document-handling in section 4.2 so that it will be easier for
> readers to understand their interaction.
>> With the above changes, all of the job template attributes that make sense
> for being per-document MAY be supported with Send-Document and Send-URI
> operations.
>>> 2. Since section 3.3.1.1 indicates that these job template attributes are
> OPTIONAL as document attributes, a client needs to be able to tell which are
> supported as per-document attributes and which are supported only as job
> attributes. Therefore, we propose adding a "document-attributes-supported"
> Printer description attribute in which the Printer returns the keyword names
> of the Job Template attributes that it supports as document attributes in
> the Send-Document and Send-URI operations.
>>> 3. We need to clarify what happens when a client supplies a job template
> attribute at the job level in a Create-Job operation and then also specifies
> the same attribute (with a different value) as a document attribute in the
> Send-Document or Send-URI operation. We think that the attribute specified
> at the document level should override the value of the attribute specified
> at the job level, but only for the documents to which the document attribute
> is specified. Thus the job level attribute specifies for any documents that
> don't have that attribute specified.
>> For the three attributes that are counts: "document-k-octets",
> "document-impressions", and "document-media-sheets", the value at the job
> level, if supplied SHALL be the sum for the entire job, while the value at
> the document level, if supplied SHALL be for that document alone. So for
> these three (extensive) attributes, the document level doesn't overide the
> job level attribute, but, instead complements it.
>>> 4. On Get Attributes, we need to clarify that, depending on implemenation,
> the Printer MAY either:
> (1) factor out common document attributes and report them as job attributes,
> instead of document attributes
> (2) return all document attributes at the document level, regardless of how
> the client has specified them
> or
> (3) preserve the job versus document attributes as supplied by the client,
> since the semantic interpretation of all three representations of a job
> SHALL be the same.
>>