attachment-0001

<!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 have finished the current design for composite features.</FONT></DIV> <DIV><FONT size=2>Find the schemas and sample xml files on the UPDF site.</FONT></DIV> <DIV><FONT size=2></FONT> </DIV> <DIV><FONT size=2>I suppose everybody has a feeling now what you can accomplish with composite features (c.f. called below). You can basically combine any two or more basic features to a higher level feature. Thinking this over you may better understand why we make some feature pretty basic. I consider it a significant advantage having the chance to save the settings of all basic features, but show something more user friendly in the UI.</FONT></DIV> <DIV><FONT size=2>The sample implementation on the web site shows a 'Media' c.f. with media size, type and source involved. Might be a common sample. We will develop another more elaborate sample in the area of booklets the next days. If you follow that and understand each detail, you should have the essence of c.f. very well. Do you remember that I referred to c.f. as one of the four pillars more than a year ago? Now you may see why I like it so much. Not to mention that I consider it unique to UPDF.</FONT></DIV> <DIV><FONT size=2>Some things you may want to check in detail:</FONT></DIV> <DIV><FONT size=2></FONT> </DIV> <DIV><FONT size=2>1. See the DominantFeature attribute to the CompositeFeatureList. We don't force a driver to work a certain way, but recommendations may help with a better support. That attribute is single, optional. Means it can refer to one feature. In the sample it's media size.</FONT></DIV> <DIV><FONT size=2>If there is a dominant feature I would recommend to show the defined c.f. in the UI, but automatically remove the composing features from the normal dialogs and make them available in a subdialog collectively. This is an assumption we make in the UPDF standard.</FONT></DIV> <DIV><FONT size=2>If there is not, you may leave them at their usual locations in the standard dialogs. You can always define additional interdependencies to hide the one or the other control.</FONT></DIV> <DIV><FONT size=2>With a dominant feature the special c.f. kind of overwrites the dominant feature. That's why we have an optional Name_ID to the CompositeFeature element. In the sample we want media size to be overwritten by Media and the new Name_ID shall be reported to the OS and then show up in the page setup of the applications. Makes sense?</FONT></DIV> <DIV><FONT size=2>If you want to practice, here's the proposed task: Combine all media types and sources into one merged list of sources like used in a number of today's drivers. And now judge how much code you may need to accomplish that in a monolithic driver - just for this single implementation.</FONT></DIV> <DIV><FONT size=2></FONT> </DIV> <DIV><FONT size=2>2. If you have a dominant feature, it makes all the other features of a c.f. non-dominant automatically. In our sample that's especially the case with media source. We don't want all the media sources to show up in applications' page setup any more. It would open the door to misselections. We only want the AutoSelect to show up or we could even create a dummy media source with a string "Source is selected by size".</FONT></DIV> <DIV><FONT size=2>That leads us to the Non_Dominant_Representative attribute, assigned to all feature lists. It's mostly mandatory (only optional for media size and c.f.) and defines one record of the corresponding feature as the fall back to be used within c.f., e.g. given above mentioned dummy or the AutoSelect record. Another nice side effect is that you made the entry unchangeable (as it is just one).</FONT></DIV> <DIV><FONT size=2>This attribute handles some useful stuff when it comes to communicating setting to the OS.</FONT></DIV> <DIV><FONT size=2></FONT> </DIV> <DIV><FONT size=2>3. The UserExtensible attribute to the CompositeFeatureList is a boolean and indicates that the driver shall allow the user to create and manage his/her own records additionally to the predefined ones, if set to true. It's up to the driver how to implement that properly.</FONT></DIV> <DIV><FONT size=2></FONT> </DIV> <DIV><FONT size=2>I hope the other stuff is more or less self-explaining. We have learnt some of our lessons by practicing. During practice there certainly will be the point when you'll say "Wow! Not bad. Now I know."</FONT></DIV> <DIV><FONT size=2>We are working on a sample driver to allow you trying your sample out.</FONT></DIV> <DIV><FONT size=2>As I always say: Now that I have that stuff in my mind at a leading position, you'd get quite some solid answers to any questions.</FONT></DIV> <DIV><FONT size=2></FONT> </DIV> <DIV><FONT size=2>Norbert Schade<BR>69 Prescott Drive<BR>North Chelmsford, MA 01863<BR>978-251-1017<BR><A href="mailto:norbertschade@mediaone.net">norbertschade@mediaone.net</A></FONT></DIV></BODY></HTML>