Subject: IPP> MOD - Future change: early binding of defaults: more understandable

From: Tom Hastings <[email-masked]>
Date: Mon, 2 Feb 1998 14:37:08 PST

This is one of the future extensions that we didn't get time to discuss
at the IPP meeting last week, though I handed out the paper.  This
paper is an updated version of that paper.

I've copied the .doc, .pdf, and .txt files to:

ftp:/ftp.pwg.org/pub/pwg/ipp/new_MOD/clearer-defaulting.doc
ftp:/ftp.pwg.org/pub/pwg/ipp/new_MOD/clearer-defaulting.pdf
ftp:/ftp.pwg.org/pub/pwg/ipp/new_MOD/clearer-defaulting.txt

The .txt file follows:

Subj:  Future Model change: early binding of defaults is more understandable
       to end-users
From:  Tom Hastings
Date:  2/2/98
File:  clearer-defaulting.doc

This paper proposes a future upwards-compatible tweak to the Model
document that preserves the current semantics for attribute defaulting
(default value is used only if the PDL does not contain a corresponding
embedded instruction), but makes it clearer to the end-user what the
default values are/were for the end-user's job.  This tweak also allows
the system administrator to change the defaults on a Printer object
without affecting any submitted jobs, thereby allowing us to drop the
warning note on page 60.

The idea is for the Printer object to copy its "xxx-default" attributes
and values to the Job object in the create operation for any supported
attribute that the client does not supply.  In other words, the "xxx-
default" value is bound to the Job object at create time, instead of
using the Printer object's value at job processing time.  Since the name
of the Job attribute is "xxx-default", not "xxx", it is clear that the
value is used only if the document data does not contain an equivalent
instruction.  This is "early" binding of defaults to the Job object.

The user can query the Job object before or after the job is printed to
see what the defaults are/were.  This is particularly helpful to a user
who is surprised at his/her print job results and wants to check what
attributes the job had (while the job is in the 'completed' state).  It
is also helpful to the user while the job is in the 'pending' or
'pending-held'state.

The simplest change is to extend the definition of Job Template Job
attributes to include the "xxx-default" attributes (column two of the
table in section 4.2).  Then the Get-Attributes operation returns both
"xxx" and "xxx-default" Job object attributes (in response Group 3) when
the requester supplies the "job-template" value in the "requested-
attributes" operation attribute.

The changes to the Model document are not that many (page/line numbers
refer to the ipp-model-980116.pdf version):

1.   Page 15, lines 521-523: modify the explanation of job template Job
  attributes:

  "job-template" attributes:  These attributes are OPTIONALLY supplied
  by the client or end user and include job processing instructions
  which are intended to override any Printer object defaults and/or
  instructions embedded within the document data. (See section 4.2)

  to give:

  "job-template" attributes:  These attributes are either "xxx" or
  "xxx-default" attributes. The "xxx" attributes are OPTIONALLY
  supplied by the client or end user and include job processing
  instructions which are intended to override any Printer object
  defaults and/or instructions embedded within the document data.  The
  "xxx-default" attributes supplied by the Printer object when the
  client does not supply the corresponding "xxx" attribute.  The "xxx-

                                                                       1
 
  instructions embedded within the document data. (See section 4.2)

2.   Page 20, line 705, add to the description of Job Template attribute
  the phrase: "and which were supplied as defaults by the Printer
  object in case the document contains no such corresponding
  instructions embedded in the data" to give:

  The Job object can later be queried to find out what Job Template
  attributes were originally requested in the create request and which
  were supplied as defaults by the Printer object in case the document
  contains no such corresponding instructions embedded in the data, and
  such attributes are returned in the response as Job Object
  Attributes.

3.   Page 20, line 709, delete the phrase ", though such attributes are
  returned in the response as Printer Object Attributes" to give the
  following:

  The Printer object can be queried about its Job Template attributes
  to find out what type of job processing capabilities are supported
  and/or what the default job processing behaviors are, though such
  attributes are returned in the response as Printer Object Attributes.

4.   Page 33, after line 1168, add the following bullet to the list:

       - Copies its "xxx-default" attributes to the Job object for any
       "xxx" Job Template attribute not supplied by the client.

5.   Page 33, lines 1169-1171, change the last bullet from:

  - at job processing time, uses its corresponding default value
  attributes for the supported Job Template attributes that were not
  supplied by the client as IPP attribute or embedded instructions in
  the document data.

  to:

  - at job processing time, uses the Job's "xxx-default" attributes for
  the supported Job Template attributes that were not embedded
  instructions in the document data.

6.   Page 48, lines 1708-1709, replace "first column" with "first and
  second columns" in the description of the "job-template" attribute
  group name in the Get-Job-Attributes operation description to give:

  - 'job-template': all of the Job Template attributes that apply to a
  Job object (the first and second columns of the table in Section
  4.2).

7.   Page 60, line 2084, add the sentence:

  The Printer object indicates its default value for each "xxx"
  attribute by copying its corresponding "xxx-default" attribute and
  value to the Job object as part of the create job operation.

8.   Page 60, lines 2086-2088, delete the note:

  Note: Since an administrator MAY change the default value attribute
  after a Job object has been submitted but before it has been
  processed, the default value used by the Printer object at job
  processing time may be different that the default value in effect at
  job submission time.

9.   Page 61, lines 2120:2127, indicate that column two (xxx-default) is a
  Job Template attribute for both the Job and Printer objects as
  follows:

  The table below summarizes the names and relationships for all Job
  Template attributes.  The first two columns of the table (labeled
  "Job Attribute") show the name and syntax for each Job Template
  attribute in the Job object. These are the attributes that can
  optionally be supplied by the client in a create request.   The last
  two columns (labeled "Job/Printer: Default Value Attribute" and
  "Printer: Supported Values Attribute") shows the name and syntax for
  each Job Template attribute in the Printer object (the default value
  attribute and the supported values attribute).  A "No" in the table
  means the Job and Printer SHALL NOT support the attribute (that is,
  the attribute is simply not applicable).  For brevity in the table,
  the 'text' and 'name' entries do not show (MAX).

10. Page 62, line 2129, change the column two heading from "Printer:
  Default Value Attribute" to "Job and Printer: Default Value
  Attribute"

11. Page 151, lines 5134-5135: add to the end of the sentence:

  by copying its "job-priority-default" attribute and value to the Job
  object

  to give:

  IF NOT supplied by the client, use the value of the Printer object's
  "job-priority-default" attribute at job submission time by copying
  its "job-priority-default" attribute and value to the Job object.

12. Page 151, lines 5145:5146: add to the end of the sentence:

  by copying its "job-hold-until-default" attribute and value to the
  Job object

  to give:

  IF NOT supplied by the client, use the value of the Printer object's
  "job-hold-until-default" attribute at job submission time by copying
  its "job-hold-until-default" attribute and value to the Job object.

13. Pages 155-156, lines 5300:5302:  add:

  and the corresponding Printer object's "xxx-default"  is copied to
  the Job object

  to give:

  If an attribute has no values after removing unsupported values from
  it, the attribute is removed from the Job object and the
  corresponding Printer object's "xxx-default"  is copied to the Job
  object (so that the normal default behavior at job processing time
  will take place for that attribute).

14. Page 156, lines 5304:5306:  add:

  and the corresponding Printer object's "xxx-default"  is copied to
  the Job object

  to give:

  If an attribute has no values after removing conflicting values from
  it, the attribute is removed from the Job object and the
  corresponding Printer object's "xxx-default"  is copied to the Job
  object (so that the normal default behavior at job processing time
  will take place for that attribute).

15. Page 156, line 5318, add:

  (but not "xxx-default") to give:

  Note: All "xxx" (but not "xxx-default") Job Template attributes that
  are persistently stored with the Job object are intended to be
  "override values"; that is, they that take precedence over whatever
  other embedded instructions might be in the document data itself.

16. Page 156, lines 5323:5328, change the paragraph to describe copying
  the "xxx-default" Printer object attributes to the Job object, to
  give:

  There are some cases, where a Printer supports a Job Template
  attribute and has an associated default value set for that attribute.
  In the case where a client does not supply the corresponding
  attribute, the Printer copies its "xxx-default" attributes to
  populate Job attributes when creating the new Job object. These
  copied Job default values are only used later at Job processing time
  if no other IPP attribute or instruction embedded in the document
  data is present.

17. Page 156, lines 5329:5335, change the first sentence of the note to
  explain the copying of the lower precedance "xxx-default" attributes,
  rather than "xxx" to the Job object, giving:

  Note: If the default values associated with Job Template attributes
  that the client did not supply were to be used to populate the Job
  object as "xxx" (instead of "xxx-default") attributes, then these
  values would become "override values" rather than defaults. If the
  Printer supports the 'attempted' value of the "pdl-override-
  supported" attribute, then these override values could replace values
  specified within the document data.  This is not the intent of the
  default value mechanism. A default value for an attribute is used
  only if the create request did not specify that attribute (or it was
  ignored when allowed by "ipp-attribute-fidelity" being 'false') and
  no value was provided within the content of the document data.