Scott A. Isaacson wrote:
>> Keith Carter and I met and we want to run the following issues by the
> team:
>> We want to have a Location attribute. We propose that this should be a "
> a free form string that can contain any site specific location information."
> How should filtered searches work on values of this attribute?
If this string contains site-specific information, then standardized
filtered
searches would only work with a pre-defined nomenclature using keywords
and/or
some type of BNF or fairly rigid syntax. Keywords could be defined, with
the
associated values being the secondary key components (the first search
component
being the keyword in a "search by keyword-value pair" scenario).
I would offer that there is a URN (Uniform Resource Name) working group
looking into
persistance and location-based naming for network resources. I believe
drafts are
available on their current work.
Also, since this information is site-specific, does it suggest a
usefulness only in
the "intranet" domain, as opposed to "internet" domain?
>> We want to introduce a new attribute callled Print Quality. "This indicates
> a somewhat subjective evaluation of the overall printing quality: "high",
> "medium", or "low" " ISSUE: Does this subsume the need for Resolution
> and Speed?
I do think that "print quality" might obviate the need for resolution,
but probably not
for speed, since alot of the time (depending on the device) they could
be inversely
proportional. (i.e., it quicker to print "draft" than
"highest-resolution").
>> We want to introduce a new attribute called Cost. "This indicates a
> somewhat subjective evaluation of the overall cost of printing at this
> printer: "high", "medium", or "low". " ISSUE: Is this a good thing or not?
We could also assume here that cost might be directly proportional to
"print quality"
mentioned in the previous paragraph. Some 1st order normalization of
these attributes
is obviously going to be a key goal of future meetings.
>> We propose a Fonts Supported attribute which is the same as the
> fonts-supported attribute in the Printer object. ISSUE: Do you agree that
> this should be in the directory entry. Some studies have shown that
> users want to search for printers based on this attribute.
>> If we keep Maximum Speed should it be moved to "high, med low"??
>> We propose a P1284 Device ID not a plug and play Id -- the plug and play
> id can be created from this. ISSUE: Does this subsume the need for
> Make, Model, and Type??
It probably would if the only path to the particular device pointed to
by this entry
is via a 1284 interface.
Just my $0.02 (or more)
Randy
>> ************************************************************
> 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> ************************************************************