If we want to go down the slippery slope that Tom proposes, I have an
alternate proposal to Tom's which avoids some of the problems in his
proposal. My proposal is that the default behavior of a server be for
it to support NO document attributes, but that a server implementation
can support any attribute on a document basis. This allows servers to
conform to the standard and ignore this whole thorny problem of
document attributes.
If we have the attribute document-attributes-supported that Tom
proposes, an implementation that doesn't support document attributes
need not support this attribute either.
If an attribute-name is a member of the document-attributes-supported,
then the server supports that attribute with either its standard type,
e.g. key-word or with a dictionary value where that dictionary contains
an attribute named "default" for the job level behavior and one
additional attribute for each document which is different. Such an
attribute could be named '1' for the first document, '2' for the second
one, etc. This leaves all information in the PrintJob/CreateJob operation
for easy validation.
For example, if media is letter for all documents in a job, then its
value is "letter". If documents 1,2 and 4 four are letter but document
3 is legal, then media is a dictionary with two sub-attributes:
"default" has the value of "letter" and "3" has the value of "legal".
If "media" is not a member of document-attributes-supported or
document-attributes-supported is not a supported attribute in the
printer, the server treats a dictionary type for media as an unsupported
value and either rejects the job (fidelity is true) or does
substitution (fidelity is false).
Should we want to move ahead with Tom's proposal, and I don't know that
we do, then I think that my proposal offers a better way for different
levels of support.
My 2 cents.
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.
>>