This is a very controversary item and probably the one with the most confusion about.
1. The attribute ID currently is the attribute uniquely identifying a certain record of an element like a feature, e.g. media size or device resolution.
ID has to be unique per UPDF description, but can have any form (ID_5, Norbert_s_size, 234, size80, etc.). Generally it's useless to try to interpret ID.
2. Additionally to ID we have a number of classifying attributes with technical meaning. The entries in most if not all cases follow certain rules. They can be interpreted.
Samples for classifying attributes are Predefined_ID/Proprietary_ID, KB, HorizontalResolution, etc.
Excerpt for Predefined_ID/Proprietary_ID
I tried to explain this a number of times. I'll try again.
We need a way to sometimes select from a list of predefined keywords (like coming from the standardized media names specification or from our own UPDF specification), but still be able to enter another value. This requires an editable combo box. That's not possible under the XML applications I know of. So we built a work-around by specifying one attribute Predefined_ID, where all the predefined keywords are listed, plus another attribute Proprietary_ID, where somebody can enter an arbitrary value (if we haven't defined a list of keywords, you may only see the one attribute Proprietary_ID). If a feature uses both attributes, we understand them as one merged list. To do that we add one more predefined keyword to the list called 'proprietary-media-size' (or similar). The rule is to look for the keyword in Predefined_ID, but in case that attribute shows 'proprietary-media-size' (or similar) look in Proprietary_ID. By that mechanism we have created something like an editable combo box. That's why I show the two attributes together in most cases separated by a slash.
I hope you're with me so far.
In my world (and believe me I know it may not represent the whole world) I would save the unique ID in my driver, whenever I save the current setting of a feature. Under Windows that's done mainly in the registry, but another mechanism wouldn't make a difference for me.
To the operating system or application I would always announce classifying attributes like I'd find in Predefined_ID/Proprietary_ID for media size or in HorizontalResolution and VerticalResolution for device resolution, etc.
In interdependencies I would be allowed to work with the unique ID as well as with some classifying attributes (could be discussed). Classifying attributes may make some interdependencies shorter.
Classifying attributes in my view are not necessarily (but often) unique. You may have a device resolution record for a true 600 dpi and another for a FastRes (600 dpi with another PJL command). Other cases with other features can be composed.
That would mean the classifying attribute the driver/client announces to the application is not necessarily unique - for me not a problem.
One of the discussions is to make the classifying attributes unique (and therefore perhaps be able to let the attribute ID go completely, as it would not be needed any more as an additional identifyer).
I think the key statement of this email is that I'd save and work with the unique ID in my driver, but communicate classifying ID's with the OS/application.
I said earlier that this item affects item 12.
We have to decide whether we want to save defaults with the unique ID or differently.
Regards
Norbert Schade
Principal Software Engineer
Advanced Development / Connectivity
Oak Technology, Inc.
10 Presidential Way
Woburn, MA 01801
USA
Phone: 1-781-638-7614
Fax: 1-781-638-7555
email: norbertschade@oaktech.com
This archive was generated by hypermail 2b29 : Fri Sep 14 2001 - 14:36:18 EDT