We need more discussion on that issue.
this is part of item 5 of the Tampa agenda.
We have agreed so far that the same set of dtd files would be used for any installable option, so you would have a new set of XML files for any installable option. that will make it easy to remove it again at any time.
Definition
I consider any piece of hardware, which can be physically removed from the peripheral device, an option.
This may include RAM cards, input options, output options, duplexers or anything else.
Rule 1: Do not specify any option in the master description.
Options may come with the device - as part of the original shipment. Or they can be bought and added later. Newer options may even replace older ones.
Required features
Any driver should provide some functionality to ensure that at least one element is available for certain features. For printers these features include input and output features (to be discussed). RAM?
So in most descriptions a master description would include an input feature, but in theory it doesn't need to. The printer could be shipped with one or more default options. Same with RAM.
Now how do we specify that in detail?
I see three chances to do that.
1. We could do something with the file names.
Primitive sample: Printer ABC Master.xml, Printer ABC Option 2 Input Trays.xml, Printer ABC Option Duplexer, etc.
Looks doable. Advantage would be to have an easy search for options when you have the master description.
Sounds a bit artificially constructed and wooden.
2. We could provide some fields internally.
We could create a field "Master Unit". In case this fields entry matches the unit name of the description, it must be the master. Otherwise this field would list the unit name of the master description.
The master field would be repeatable to be able to tell that a certain unit can be added to a number of master descriptions.
Sounds a little more sophisticated, but I'm not sure about searching performance and confusions at run time.
3. We could work with a config file.
I think this requires either the implementation of option 2 or an additional install file for docking information per installable option.
Then the config file is the real data entry point for the driver.
It has to hold an entry for the master unit plus a more or less infinite number of optional units.
All listed units are active. Deactivated units have to be removed from the config file.
Adding an installable option would mean searching for an XML file, where the first entry is "Docking Information" (so called docking files), and then read whether the current master unit is listed in the list. Then add it to the XML file, where the first entry is "Configuration Information" (so called config files). This would not require any file naming conventions.
I must admit that version 3 is my favovite.
I will write some primitive sample docking and config files for demonstration later today and send them around.
Any other proposal? What is your favorite?
In all versions we agree that the description of the optional unit is based on the same set of dtd files as the master unit. Typically the master unit is the biggest description. That gives us the chance for all times to add an installable option with any feature.
Unsolved challenges
1. I am concerned about the UI representation of it. In many drivers this part is shown on a config tab.
In case a driver shows any optional unit as a separate check box, no problem.
In case a driver shows all optional unit in a multiselect list box, no problem.
Anything else gets difficult.
We haven't created something like categories for installable options (input options, output options, etc.). The danger with categories is to anticipate the future. Do all options fit into the categories? Will there be additional categories in future?
Free for discussion.
2. Constraints is a heavy duty.
There are two questions.
First is how to solve the problem that certain units cannot be attached the same time?
Second is how to specify feature constraints (duplex may not work for all trays) with installable options in mind, which are yet unknown.
Anyhow I think it is important to know about limitations, even if we don't solve them all.
Ok, now it's up to you to think about it. As in many cases I develop some basic ideas and ask for improvement and polishing. I'm always trying to keep a concept as open as possible for future extensions.
Regards
Norbert
This archive was generated by hypermail 2b29 : Wed Feb 28 2001 - 15:33:11 EST