I'm somewhat concerned about removing them from V1.0, because adding
them later is a bigger step than just adding yet another attribute.
xxx-available introduces the concept of parallel multiple-valued
attributes. It may come as a shock to implementors that implemented
multiple-valued atributes, say as a bit mask in V1.0, to discover that
the values are ordered, not just an unorderd set.
However, we might reduce the number from 6 to a smaller number.
The current attr-05f.doc file had the following 6 xxx-available attributes:
media-available
number-up-available
sides-available
printer-resolution-available
print-quality-available
finishings-available
I'd be happy if that were further reduced to say, just:
media-available
finishings-available
since for the others the supported values are almost always ready.
>
>
>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.
Exactly why I'm concerned about removing xxx-available entirely.
>
>
>> 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..
>*****
Looks like good simplification.
Tom
>************************************************************
>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@novell.com
>W: http://www.novell.com
>************************************************************
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>