Scott asked for comments on a proposal to use tables to describe
job template attributes in the model document. I've sat here this morning
thinking about how to make this attribute stuff comprehensible and have
the following proposal:
First of all, we should clean up the sections that provide over-all description
of attributes. Get these sections crisp, clear and concise. There is some
wording in section 4.5.1 of the current model document that suggests that
there are several kinds of attributes: Printer attributes, Job attributes, and
attributes that go into print requests. Although these have the same names
and syntax they are somehow different attributes. I think it would be much
simpler if we looked at it from the point of view that attributes are just
attributes
and by the way I can use them to describe printer capabilities or request
specific job instructions. This may seem subtle, but I think would help the
words a lot.
Secondly, I continue to struggle with the notions of xxx-supported and
xxx-available. As we hone in on the actual encoding of this stuff
across the wire, I'd like to propose that we go back to Herriot's original
notion of adornments. I think that we could very easily adopt an encoding
scheme that allowed us to flag default and available attribute values.
I'm particularly troubled by the wording in section 6.2 of the current model
document (lines 1368-1379) that "there is no general rule for associating
"xxx" with "xxx-supported" ..." I believe that adornments will give us a
very much simpler model that what we currently have.
If we take job priority as an example, on the wire why coudn't I have an
encoding something like
job-priority : 1-5, 1(D)
meaning that job priority must be an integer in the range 1-5 and 1 is the
default. Available could likewise be flagged for attributes to which it
applies.
Finally, if the overview is crisp, we should not have to write unique
sections (or entries in a table) for every attribute variation. When I
read the current model document most of what's there in the attribute
descriptions is just a rehash of how an attribute works. I think it only
adds a lot of unnecessary verbage and makes the document
hard to read and appear complex. Given a good foundation, I believe
that the only unique bit I need for each attribute is the default behaviour
and whether or not it supports adornments.
For example (compare this to section 6.2.5 of the current model document):
6.2.5 job-priority (integer (1:100))
This attribute specifies a priority for scheduling the print job. Printers that
emply a priority based scheduling algorithm must support this attribute.
A higher value specifies a higher priority. The value 1 is defined to indicate
the lowest priority. Priority is expected to be distributed normally across
this range. A Printer shall print all jobs with a priority value of n before
printing any jobs with a priority of n-1 for all n. The mapping of vendor
defined priority over this range is implementation specific.
6.2.5.1 Default behavior
If a Printer does not implement job-priority, the Printer shall treat all jobs
as if they had the same priority.
6.2.5.2 Adornments
The job-priority attribute supports the "default" adornment..
Roger K deBry
Senior Techncial Staff Member
Architecture and Technology
IBM Printing Systems
email: rdebry at us.ibm.com
phone: 1-303-924-4080