Bob Herriot
> From rdebry@us.ibm.com Wed Apr 23 10:10:14 1997
>
>
> o If the client supplies an attribute group that is implemented
> by the Printer, the Printer shall respond with all currently
> supported values for each implemented attribute in the group.
> It shall not respond for unimplemented attributes in the
--------------------------------------------------------
> group. If the value of an attribute is unknown for any
------
> reason, the Printer shall respond with the value "unknown" for
> that attribute.
The underlined sentence is meaningful for attributes in the standard
that the Printer doesn't implement, but not for other undefined and
unimplemented attributes like "foobar".
I assume that GetAttributes of a group does not return job attributes
which acquired the value of unsupported for the case where a job
submission includes an unsupported attribute, even for those
unsupported attributes defined in the standard. The one exception is
the group "all". This is because the Printer doesn't know what group it
belongs to except for the group "all".
>
> Each job and document attribute implemented by a Printer must
> have a defined default value. This value will be the first value
> returned in response to a query on that attribute. Furthermore,
As my previous email stated, I disagree with the notion that the first
value is the default. This may simplify things, but it doesn't solve
the integer range case. This rule may be a good fallback rule for the
case where there is not an explicit default, but I think we need a
mechanism for defining default values. I have suggested that a naming
convention, such as "default-XXX" or "XXX-default" be used as the
default for "XXX". Or perhaps printer attribute XXX contains the default value
for job attribute XXX and the printer attribute "XXX-supported" contains
the supported values.
If you are looking for simplification, I would prefer to reduce the number
of groups to two for each object rather than give up the defaulting
mechanism. The two groups for each object (Job and Printer) would be
JobTemplate and xxxStatus. All attributes in the current JobTemplate group
would remain in JobTemplate, but without any subgroups (at least as
knowledge within the implementation). All other job attributes would
be in the JobStatus group and all other printer attributes would be in
the PrinterStatus group.