I think that we can just describe the semantics of each xxx Job attribute
and not the xxx, xxx-supported, and xxx-available Printer attribute,
just list the allowed forms (as in Jay's proposal).
Then up front we have a single discussion about the semantics of the xxx,
xxx-supported, and xxx-available Printer attributes.
One possibility that may make things more understandable, is to NOT
have the same name for the Job and Printer attribute. For the Printer
attribute algorithmically add: "-default".
Also I don't want to lose the current data type in the header, so that
the table of contents is a simple listing of the attributes. Job template
attributes are only listed once as xxx, and the xxx-default, xxx-supported,
and xxx-ready don't get listed in the table of contents.
I don't think that we need the Mandatory in the header and TOC, since
not all corresonding xxx-yyy Printer attributes will wind up in the TOC.
I also suggest that the forms should come first, like a program
description of procedure calls or UNIX man pages.
For forms that aren't allowed, just don't list them. If no default,
don't list it, if no available, don't list it.
So Jay's suggestion would become (for the job template attributes only):
6.2.1 xxx (type4 keyword)
Create request: xxx (type4 keyword) (OPT/MAND/etc)
Job object: xxx (type4 keyword) (OPT/MAND/etc)
Printer object: xxx-default (type4 keyword) (OPT/MAND/etc)
Printer object: xxx-supported (1setOf type4 keyword) (OPT/MAND/etc)
Printer object: xxx-available (1setOf type4 keyword) (OPT/MAND/etc)
Description...
The standard values for named time periods are:
'no-hold': immediately....
'aaa': blah blah ....................................
blah blah
'bbb': blah blah
6.2.2 yyy (integer(1:100))
Create request: yyy (integer(1:100)) (OPT/MAND/etc)
Job object: yyy (integer(1:100)) (OPT/MAND/etc)
Printer object: yyy-default (integer(1:100)) (OPT/MAND/etc)
Printer object: yyy-supported (rangeOf integer(1:100))(OPT/MAND/etc)
Description...
Then the simpler non-job-template job and printer attributes would simply be:
6.3.1 zzz (type1 keyword)
Job object: zzz (type1 keyword) (OPT/MAND/etc)
Description...
The standard values for job states are:
'no-hold': immediately....
'aaa': blah blah ....................................
blah blah
'bbb': blah blah
6.4.1 mmm (integer(0:2**31-1)
Priner object: integer(0:2**31-1) (OPT/MAND/etc
Description...
At 07:50 05/30/97 PDT, Roger K Debry wrote:
>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@us.ibm.com
>phone: 1-303-924-4080
>
>