I will post a document to the ftp server later today, but I did want to sent
out the notes from our meeting:
MODEL MEETING 1/9/97 Afternoon
Action Items:
Review the attributes for existence, semantics, and syntax.
Editor adds fan in text as an option
Editor adds text describing uses for make and model (1 filtering, 2
linking with a driver)
Editor give examples for state-messages
Jim will determine if there is a need for mandatory attributes
values supplied and if so how
Fix the attributes according to Tom's proposal. (see below)
Discussion
1. Do we add "fan in" back into the document? We can have multiple
printer objects for the same output device. If there are multiple printers
for the same device, what about the admin experience of updating one
attribute and have it flow through to the others? This is an
implementation issue. Should we introduce a constraint object? Not at
this point. Should we implement a Logical Printer and a Physical Printer to
allow fan out? Not at this point.
2. Should we add device id attribute? Recommend IEEE 1284 device ID.
Could be multivalued.? Lots of ohhs and ahhs and oh no! No,
singlevalued. Should all of the "physical" type attributes be multivalued
because of fan out? No. Location describes it at the level of granularity
necessary for finding the output. Do we want to add a new state value
called "multiple" that is a hint to go look at multiple object states? No.
State Values: Idle, Unknown, Processing, Needs Attention
3. Empty string is different from Null Value. Some attributes are
mandatory. Some are not.
4. We discussed the following issue:
Right now, the I-D proposes Job attributes and Printer attributes some of
which are related by the following relationship: Printer attributes can be
xxx-supported with multiple values, one of which might be a default
value. There can be the same xxx-requested attribute in a Job that
requests an override to the default be explicitly calling out the value to
use. Tom suggested that there is a way for the SAME attribute be used
for all forms of use: what is supported, what is the default, and what is
requested. So instead of having a media-supported Printer attribute
(with some default) and a separate media attribute which is a Job
attribute, we have one attribute which is a media attribute. The syntax
changes upon its usage which may be a problem.
5. Attribute values are adorned with qualifiers that show what state the
value is in. For example, a certain medium value can be loaded, ready,
on the shelf, on order, etc.
-----------------------------
Since I will not be present at 1/15 telecon, we need to driver our issues
over e-mail so that all can participate. When we have taken action on the
above issues list, please post notice to this mailing list.
Scott
************************************************************
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
************************************************************