IPP>MOD - attribute description in Model document

IPP>MOD - attribute description in Model document

IPP>MOD - attribute description in Model document

Tom Hastings hastings at cp10.es.xerox.com
Fri May 30 15:57:38 EDT 1997


At 08:37 05/30/97 PDT, Scott Isaacson wrote:
>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.


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 at novell.com
>W: http://www.novell.com
>************************************************************
>
>
>                                                                            
>                                                                            
>                                                                            
>                                                                            
>                                                                            
>                                                                            
>                                                                            
>                                                                            
>                                                                            
>                                                                            
>                                                                            
>                                                                            
>                                                                            
>                                                                            
>                                                                            
>                                                                            
>                                                                            
>                                                                            
>                                                                            
>                                                                            
>                                                                            
>                                                                            
>                                                                            
>                                                                            
>                                                                            
>                                                                            
>                                                                            
>                                                                            
>                                                                            
>                                                                            
>                                                                            
>                                                                            
>                                                                            
>                                                                            
>                                                                            
>                                                                            
>                                                                            
>                                
>
>



More information about the Ipp mailing list