Some addiitonal comments follow .......
The problems are only with the "job template" attribtes.
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.
RKD> I am really hung up on two issues:
RKD> The first is just the comprehension issue, which to some
RKD> extent can be fixed as suggested above.
RKD> The second issue is one that I caught when re-reading
RKD> the document for the nth time and thinking about the
RKD> code problem in dealing with different attribute names
RKD> and trying to correlate them. That's why going back
RKD> (atleast on the wire) to a flag or an adornment makes
RKD> better sense to me. It would make the client code much
RKD> easier to write and much less prone to errors if the
RKD> notion of an adornment or flag to the base attributet
RKD> were used.
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".
RKD> Please **NO**. I think that only complicates things.
RKD> The biggest problem I have when reading the document
RKD> is dealing with all of these different kinds of attributes.
RKD> Giving them a different name only makes the problem worse
RKD> in my mind.
... snip ...