Subject: IPP> MOD - document format question

From: Roger K Debry <[email-masked]>
Date: Thu, 29 May 1997 18:12:43 -0400

My first reaction is that if we need this many boxes to talk about an
attribute, then
we still have too much complexity built into the model.  Before spending the
time to
rewrite all of the this into a new format, I'd really like to see the new pages
that describe
what these variations all are, when each is used, and so on.  I think that this
section of the
document is ultimately an order of magnitude more important than the specific
description for each attribute.

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

---------------------- Forwarded by Roger K Debry/Boulder/IBM on 05/29/97 03:59
PM ---------------------------

        ipp-owner @ pwg.org
        05/29/97 03:51 PM
Please respond to [email-masked] @ internet

To: ipp @ pwg.org @ internet
cc:
Subject: IPP> MOD - document format question

In working on the Model document, I had several requests to come up with a
better format for all of Job Template attributes.

I used to have something like the following for each Job Template attribute:
------------------------------------------------------
1.0 xxx (syntax)
1.1 As a create request attribute: xxx (syntax, OPT/MAND/etc.)
1.2 As a Job object attribute: xxx (syntax, OPT/MAND/etc.)
1.3 As a Printer object attribute
1.3.1 Default Behavior
1.3.2 As a default value ttribute: xxx (syntax, OPT/MAND/etc.)
1.3.3 As a supported attribute : xxx-supported (OPT/MAND/etc.)
1.3.4 As an available attribute : xxx-available (syntax, OPT/MAND/etc.)
------------------------------------------------------

Now I propose something like:
(WARNING: requires some non-proportional spaced font)

------------------------------------------------------
1.0 xxx

+----------------------+-------------------+-------------------------+
| Create Request       | JOB Object        | Printer Supported       |
| Attribute            | Attribute         | Attribute               |
+----------------------+-------------------+-------------------------+
| xxx                  | xxx               | xxx-supported           |
| syntax               | syntax            | syntax                  |
| OPT/MAND/etc.        | OPT/MAND/etc.     | OPT/MAND/etc.           |
+----------------------+-------------------+-------------------------+

+----------------------+-------------------+
| Printer Default      | Printer Available |
| Value Attribute      | Attribute         |
+----------------------+-------------------+
| xxx                  | xxx-available     |
| syntax               | syntax            |
| OPT/MAND/etc.        | OPT/MAND/etc.     |
+----------------------+-------------------+

Any comments or suggestions?
Scott

---

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

Scott,

I think we need a real complete example, before we can give good feedback.

I suggest two examples: one with keyword values and one with integer values.

I would hope that we could still have our nice proportional spaced font
form, and let the IETF suffer with its fixed space format.  I've found
the solutions to making fixed space from variable spaced in WORD and will
be glad to help you.

The only concession to the plain text form, should be the typographic
convention that attribute name keywords are in double quotes (") and attribute
value keywords are in single quotes (') as the document has mostly now.

Also tables are good to avoid because they can't have line numbers in 
WORD.  Also tables create more wasted space, making our document longer.
And tables break across page boundaries, making the document harder to read.
Finally changing from proportionally space to fixed to publish is harder
with tables.

I like Jay's lean mean approach to just list the forms, one per line
and then have one description.  Don't use too many features of MS-WORD
(except table of contents now, an index later, and maybe cross references
later).

The defaults, supported, and available should not need specific description.
We should be able to specify once up front what defaults, supported, and
available means and not have any description for them.  Like the first
draft.

Thanks,
Tom

At 15:00 05/29/97 PDT, JK Martin wrote:
>Scott,
>
>If the boxed approach results in describing a single attribute in one
>"row" in the plain text draft (as opposed to two rows in your example),
>then perhaps the boxed approach might be an improvement over the existing
>implementation.
>
>If the boxed approach doesn't work, then how about a lean'n'mean tabular
>approach, such as:
>
>  1.0  xxx
>
>      Description...
>
>      Forms:
>
>	Create request:	 xxx            (OPT/MAND/etc)
>	Job object:	 xxx            (OPT/MAND/etc)
>	Printer object:	 xxx            (OPT/MAND/etc)
>	Default value:	 xxx            (OPT/MAND/etc)
>	Supported:	 xxx-supported  (OPT/MAND/etc)
>	Available:	 xxx-available  (OPT/MAND/etc)
>
>
>Just a thought on alternatives here.
>
>By the way, the fact that we have all these variations on attributes
>is a bit scary and makes me wonder if we haven't gone over the top on
>this part of the model.  ;-)
>
>	...jay
>
>----- Begin Included Message -----
>
>>From [email-masked] Thu May 29 17:49 EDT 1997
>Date: Thu, 29 May 1997 15:27:26 -0600
>From: Scott Isaacson <[email-masked]>
>To: [email-masked]
>----- End Included Message -----
>
>
>

---

From: [email-masked] (Robert Herriot)
Date: Fri, 30 May 1997 15:04:47 -0700

I like Jay's suggestion best for the formatting.

I also agree with others about eliminating redundant text.
Say it once and say what it applies to.

Bob Herriot

> From [email-masked] Thu May 29 15:10:12 1997
> 
> 
>   1.0  xxx
> 
>       Description...
> 
>       Forms:
>