Subject: IPP>MOD - attribute description in Model document

From: Roger K Debry <[email-masked]>
Date: Fri, 30 May 1997 10:50:01 -0400

Scott asked for comments on a proposal to use tables to describe
job template attributes in the model document.  I've sat here this morning
thinking about how to make this attribute stuff comprehensible and have
the following proposal:

First of all, we should clean up the sections that provide over-all description
of attributes. Get these sections crisp, clear and concise.  There is some
wording in section 4.5.1 of the current model document that suggests that
there are several kinds of attributes: Printer attributes, Job attributes, and
attributes that go into print requests. Although these have the same names
and syntax they are somehow different attributes.  I think it would be much
simpler if we looked at it from the point of view that attributes are just
attributes
and by the way I can use them to describe printer capabilities or  request
specific job instructions.  This may seem subtle, but I think would help the
words a lot.

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
across the wire, I'd like to propose that we go back to Herriot's original
notion of adornments.  I think that we could very easily adopt an encoding
scheme that allowed us to flag default and available attribute values.
I'm particularly troubled by the wording in section 6.2 of the current model
document (lines 1368-1379) that "there is no general rule for associating
"xxx" with "xxx-supported" ..."   I believe that adornments will give us a
very much simpler model that what we currently have.

If we take job priority as an example, on the wire why coudn't I have an
encoding something like

   job-priority : 1-5, 1(D)

meaning that job priority must be an integer in the range 1-5 and 1 is the
default.  Available could likewise be flagged for attributes to which it
applies.

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. I think it only
adds a lot of unnecessary verbage and makes the document
hard to read and appear complex.  Given a good foundation, I believe
that the only unique bit I need for each attribute is the default behaviour
and whether or not it supports adornments.

For example (compare this to section 6.2.5 of the current model document):

6.2.5 job-priority (integer (1:100))

This attribute specifies a priority for scheduling the print job. Printers that
emply 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.

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

Roger K deBry
Senior Techncial Staff Member
Architecture and Technology
IBM Printing Systems
email: [email-masked]
phone: 1-303-924-4080

---

From: Scott Isaacson <[email-masked]>
Date: Fri, 30 May 1997 09:37:08 -0600

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 <[email-masked]> 05/30 8:50 AM >>>
> ...

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.

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.

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

************************************************************
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: [email-masked]
W: http://www.novell.com
************************************************************

---

From: Tom Hastings <[email-masked]>
Date: Fri, 30 May 1997 10:07:39 PDT

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.

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

Also I don't want to lose the current data type in the header, so that
the table of contents is a simple listing of the attributes.  Job template
attributes are only listed once as xxx, and the xxx-default, xxx-supported,
and xxx-ready don't get listed in the table of contents.

I don't think that we need the Mandatory in the header and TOC, since
not all corresonding xxx-yyy Printer attributes will wind up in the TOC.

I also suggest that the forms should come first, like a program
description of procedure calls or UNIX man pages.

For forms that aren't allowed, just don't list them.  If no default,
don't list it,  if no available, don't list it.

So Jay's suggestion would become (for the job template attributes only):

  6.2.1  xxx (type4 keyword)

	Create request:	 xxx (type4 keyword)            (OPT/MAND/etc)
	Job object:	 xxx (type4 keyword)            (OPT/MAND/etc)
	Printer object:	 xxx-default (type4 keyword)    (OPT/MAND/etc)
	Printer object:	 xxx-supported  (1setOf type4 keyword) (OPT/MAND/etc)
	Printer object:	 xxx-available  (1setOf type4 keyword) (OPT/MAND/etc)

      Description...

      The standard values for named time periods are:
         'no-hold': immediately....
         'aaa': blah blah ....................................
                    blah blah
         'bbb': blah blah

  6.2.2  yyy (integer(1:100))

	Create request:	 yyy (integer(1:100))           (OPT/MAND/etc)
	Job object:	 yyy (integer(1:100))           (OPT/MAND/etc)
	Printer object:	 yyy-default  (integer(1:100))  (OPT/MAND/etc)
	Printer object:	 yyy-supported  (rangeOf integer(1:100))(OPT/MAND/etc)

      Description...

Then the simpler non-job-template job and printer attributes would simply be:

  6.3.1 zzz (type1 keyword)

        Job object:      zzz (type1 keyword)           (OPT/MAND/etc)

      Description...

      The standard values for job states are:
         'no-hold': immediately....
         'aaa': blah blah ....................................
                    blah blah
         'bbb': blah blah

  6.4.1 mmm (integer(0:2**31-1)

        Priner object:   integer(0:2**31-1)            (OPT/MAND/etc

     Description...

---

From: Roger K Debry <[email-masked]>
Date: Fri, 30 May 1997 17:01:25 -0400

Some addiitonal comments follow .......

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.

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

---

From: Tom Hastings <[email-masked]>
Date: Fri, 30 May 1997 09:45:06 PDT

At 07:50 05/30/97 PDT, Roger K Debry wrote:
>"xxx" with "xxx-supported" ..."   

We agreed to make the xxx-supported algorighmic, even if the English isn't
correct.  So we get medium-supported, job-priority-supported, etc.  Many
of the attributes are plural already, so there isn't any problem with
them.

>                                 I believe that adornments will give us a

---

From: Tom Hastings <[email-masked]>
Date: Fri, 30 May 1997 12:57:38 PDT

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

>problem with that would be added things like xxx-available later on.

Exactly why I'm concerned about removing xxx-available entirely.

>This attribute specifies a priority for scheduling the print job. 

Looks like good simplification.

Tom

---

From: [email-masked] (Robert Herriot)
Date: Fri, 30 May 1997 14:34:41 -0700

> From [email-masked] Fri May 30 14:08:44 1997
> 

In an earlier email you cited the sentence in the model document (lines
1368-1379) "there is no general rule for associating "xxx" with
"xxx-supported" ...".  At the San Diego meeting we decided that keyword
variants should be built in a regular fashion even if the rules for
English were violated.  We wanted xxx and xxx-supported always to be
related.  For example, it is 'media' and 'media-supported' even if it should be
'medium' by the rules of English.  This gives us the adornments that
you want without putting them in the value.

At that meeting we left undetermined whether the variant should be 
denoted by prefixes or suffixes, though currently we are using suffixes.

Bob Herriot