Thanks for taking the time to read, think, and comment.
I did not distribute the whole document so what I distributed was out of
context. I agree with most of your suggestions. Here are some of my
comments:
>>> Roger K Debry <rdebry at us.ibm.com> 05/30 8:50 AM >>>
> 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
> ...
I propose that we eliminate all "xxx-available" attributes from the model
document for version 1.0. Since it is already in place, and we know where
it fits, we know that we can always add it to a later version if necessary.
Also, the Model document says that all "supported" attributes are
CONDITIONALLY MANDATORY. Also, if the "supported" attribute is implemented,
then the default value attribute MUST be implemented as well. This means
that since the Model document describes attributes called xxx and
xxx-supported, if one is implemented the other must be as well, therefore,
there is really no reason why we could not chose to encode them
(on-the-wire) as a single structured text field as you suggest. The only
problem with that would be added things like xxx-available later on.
> 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.
> ...
100% agreed. This is what we decided at the model meeting in San Diego. We
need to describe Job Template attributes once, and then just give a clear,
concise description of each attribute under each sub-section. I am thinking
that one table at the beginning of the section on Job Templates is
sufficient (that is do NOT include a little sub table in each subsection) so
that ach subsection on each attribute just needs to be a paragraph or two.
In other words, I would simplify your suggestion as follows (remember all
syntax, naming, and implementation requirements go in the one table at the
whole section).
6.2.5 job-priority
This attribute specifies a priority for scheduling the print job.
*************
remove this since we aleady describe once what CONDITIONALLY
MANDATORY means --> Printers that
employ 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.
**** remove
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..
*****
************************************************************
Scott A. Isaacson
Print Services Consulting Engineer
Novell Inc., 122 E 1700 S, Provo, UT 84606
V: (801) 861-7366, (800) 453-1267 x17366
F: (801) 861-4025, E: scott_isaacson at novell.com
W: http://www.novell.com
************************************************************