IPP>MOD - attribute description in Model document

IPP>MOD - attribute description in Model document

Roger K Debry rdebry at us.ibm.com
Fri May 30 17:01:25 EDT 1997


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 ...



More information about the Ipp mailing list