Thanks for all of the input. I think for purposes of prototyping I will
have a Job Template residing at a print server. This template will contain
all of the attributes related to print jobs that the print server will be
able to use, will contain options for attributes in cases where different
options are enumerated and will contain default options or entries when
they can be supplied by the print server.
My scenario will then be:
1. The user will start the print client GUI and enter a URL corresponding
to a print server.
2. The user will then request the print job template and the GUI will
dynamically build a form with the attributes, options and defaults.
3. The user will modify the form if necessary, identify document files or
URLs and submit the print request.
4. The user will then be able to store the template, as filled out.
5. Then next time the user will be able to query the printer for
a template or load a template that they have filled out already. If
the template is out of date and uses incorrect attribute values then
the Print Response message would return an error.
In more detail I see an object residing at the Print Server called
Print Job Attribute Template. It would contain attributes that can be
modified by the user (with default values and multiple options where
necessary) as well as some read-only attributes that cannot be changed
by the user, but might be used by the client software to 1)Display
information of interest to user, 2) Help user determine correct
template to use in cases of multiple templates, 3) Other uses
specific to the client.
The user via the client software would then request a Print Job Attribute
Template. This template would be used by the client software to display
information and a set of choices to the user. The user would select
choices or fill in the blanks and submit a print job.
The server would then take this returned Print Attribute Job Template,now
called something like, Submission Attributes (a subset of the Print Job
Attributes) and combine these attributes with the Derived Print Job
Attributes (these being things like time of submission). The Print
Job Attributes = Submission Attributes + Derived Print Job Attributes.
If the user did not request a Print Job Attribute Template and simply
submitted a print job then the server would go to the Print Job
Attribute Template and take the default values to build a copy of the
Submission Attributes and combine these with the Derived Print Job
Attributes to form the Print Job Attributes.
I currently, for prototyping purposes, have defined the Print Job Attribute
Template to look like:
Type Att Name Att Value Att Options
----- ----------- ----------- --------------
S Printer Type Type 1 null
T Number of Copies 1 null
C Print-Off-Peak Option1 Option1 Option2 ...
L
S = Static read-only value for use by client
T = Value that will be entered by user where no choices are to
be presented as constraints(but there will be a default)
C = Value that will be one of the Attribute Options
L addresses the case, if it exists, where multiple options will be
entered as the attribute value.
The defaults will reside in Att Value and this is the field that will
be modified by the user. The Submission Attributes could just be
the fields Att Name and Att Value. For my purposes, I will probably
just "resubmit" the read-only values back to the print server, even
though the client will not change those values.
I do have a question of how the user would query a printer to find out
about template objects and how the client would get details about options
for particular attributes, as supported by a particular printer. It seems
as though querying attributes for their existence and options values would
too cumbersome. It seems like we might need an operation similar to Get
Jobs. That is, Get Templates would return a Print Job Attribute Template
object. I don't see how else we would get a template.
I will keep thinking about this. Let me know as you all have more
thoughts. Thanks, Steve