attachment

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"> <HTML><HEAD> <META http-equiv=Content-Type content="text/html; charset=iso-8859-1"> <META content="MSHTML 5.50.4611.1300" name=GENERATOR> <STYLE></STYLE> </HEAD> <BODY bgColor=#ffffff> <DIV><FONT size=2>We need more discussion on that issue.</FONT></DIV> <DIV><FONT size=2>this is part of item 5 of the Tampa agenda.</FONT></DIV> <DIV><FONT size=2></FONT> </DIV> <DIV><FONT size=2>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.</FONT></DIV> <DIV><FONT size=2></FONT> </DIV> <DIV><FONT size=2>Definition</FONT></DIV> <DIV><FONT size=2>I consider any piece of hardware, which can be physically removed from the peripheral device, an option. </FONT></DIV> <DIV><FONT size=2>This may include RAM cards, input options, output options, duplexers or anything else.</FONT></DIV> <DIV><FONT size=2>Rule 1: Do not specify any option in the master description.</FONT></DIV> <DIV><FONT size=2>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.</FONT></DIV> <DIV><FONT size=2></FONT> </DIV> <DIV><FONT size=2>Required features</FONT></DIV> <DIV><FONT size=2>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?</FONT></DIV> <DIV><FONT size=2>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.</FONT></DIV> <DIV><FONT size=2></FONT> </DIV> <DIV><FONT size=2>Now how do we specify that in detail?</FONT></DIV> <DIV><FONT size=2>I see three chances to do that.</FONT></DIV> <DIV><FONT size=2></FONT> </DIV> <DIV><FONT size=2>1. We could do something with the file names.</FONT></DIV> <DIV><FONT size=2>Primitive sample: Printer ABC Master.xml, Printer ABC Option 2 Input Trays.xml, Printer ABC Option Duplexer, etc.</FONT></DIV> <DIV><FONT size=2>Looks doable. Advantage would be to have an easy search for options when you have the master description.</FONT></DIV> <DIV><FONT size=2>Sounds a bit artificially constructed and wooden.</FONT></DIV> <DIV><FONT size=2></FONT> </DIV> <DIV><FONT size=2>2. We could provide some fields internally.</FONT></DIV> <DIV><FONT size=2>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.</FONT></DIV> <DIV><FONT size=2>The master field would be repeatable to be able to tell that a certain unit can be added to a number of master descriptions.</FONT></DIV> <DIV><FONT size=2>Sounds a little more sophisticated, but I'm not sure about searching performance and confusions at run time.</FONT></DIV> <DIV><FONT size=2></FONT> </DIV> <DIV><FONT size=2>3. We could work with a config file.</FONT></DIV> <DIV><FONT size=2>I think this requires either the implementation of option 2 or an additional install file for docking information per installable option.</FONT></DIV> <DIV><FONT size=2>Then the config file is the real data entry point for the driver.</FONT></DIV> <DIV><FONT size=2>It has to hold an entry for the master unit plus a more or less infinite number of optional units.</FONT></DIV> <DIV><FONT size=2>All listed units are active. Deactivated units have to be removed from the config file.</FONT></DIV> <DIV><FONT size=2>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.</FONT></DIV> <DIV><FONT size=2></FONT> </DIV> <DIV><FONT size=2>I must admit that version 3 is my favovite.</FONT></DIV> <DIV><FONT size=2></FONT> </DIV> <DIV><FONT size=2>I will write some primitive sample docking and config files for demonstration later today and send them around.</FONT></DIV> <DIV><FONT size=2></FONT> </DIV> <DIV><FONT size=2>Any other proposal? What is your  favorite?</FONT></DIV> <DIV><FONT size=2>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.</FONT></DIV> <DIV><FONT size=2></FONT> </DIV> <DIV><FONT size=2>Unsolved challenges</FONT></DIV> <DIV><FONT size=2>1. I am concerned about the UI representation of it. In many drivers this part is shown on a config tab.</FONT></DIV> <DIV><FONT size=2>In case a driver shows any optional unit as a separate check box, no problem.</FONT></DIV> <DIV><FONT size=2>In case a driver shows all optional unit in a multiselect list box, no problem.</FONT></DIV> <DIV><FONT size=2>Anything else gets difficult.</FONT></DIV> <DIV><FONT size=2>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?</FONT></DIV> <DIV><FONT size=2>Free for discussion.</FONT></DIV> <DIV><FONT size=2>2. Constraints is a heavy duty.</FONT></DIV> <DIV><FONT size=2>There are two questions.</FONT></DIV> <DIV><FONT size=2>First is how to solve the problem that certain units cannot be attached the same time?</FONT></DIV> <DIV><FONT size=2>Second is how to specify feature constraints (duplex may not work for all trays) with installable options in mind, which are yet unknown.</FONT></DIV> <DIV><FONT size=2></FONT> </DIV> <DIV><FONT size=2>Anyhow I think it is important to know about limitations, even if we don't solve them all.</FONT></DIV> <DIV><FONT size=2></FONT> </DIV> <DIV><FONT size=2>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.</FONT></DIV> <DIV><FONT size=2></FONT> </DIV> <DIV><FONT size=2>Regards</FONT></DIV> <DIV><FONT size=2>Norbert</FONT></DIV> <DIV><FONT size=2></FONT> </DIV></BODY></HTML>