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 6.00.2800.1106" name=GENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=#ffffff>
<DIV><FONT size=2>Last year we checked different procedures to implement 
dependencies to find out about the best implementation in UPDF. </FONT></DIV>
<DIV><FONT size=2>We did a review of dependencies these days. This includes the 
schema design as well as the specification (not yet on the web, will be end of 
week).</FONT></DIV>
<DIV><FONT size=2>Although we polished some areas for the final step of the 
draft version, we did not change the basic idea.</FONT></DIV>
<DIV><FONT size=2></FONT>&nbsp;</DIV>
<DIV><FONT size=2>We had some objectives:</FONT></DIV>
<DIV><FONT size=2></FONT>&nbsp;</DIV>
<DIV><FONT size=2>1. Where to list dependencies in the schema?</FONT></DIV>
<DIV><FONT size=2>Theoretically there are two possible solutions.</FONT></DIV>
<DIV><FONT size=2>Either you assign them to the feature to be checked once it 
gets the focus.</FONT></DIV>
<DIV><FONT size=2>Or you list all dependencies in a common pool.</FONT></DIV>
<DIV><FONT size=2>We stay with the original approach of a common 
pool.</FONT></DIV>
<DIV><FONT size=2>Advantages are maintenance (easier to be checked than looking 
all over the place) and extensibility. The latter is a unique feature of UPDF, 
as optional units and/or a user policy could have additional dependencies 
(dependencies of the master description cannot be removed nor 
edited).</FONT></DIV>
<DIV><FONT size=2>A recommendation to the driver: A dependency of an optional 
unit or user policy should have priority. However in a perfect design there 
would not occur any conflict.</FONT></DIV>
<DIV><FONT size=2>General driver procedure: First check, if there is a 
dependency with a FeatureCondition of&nbsp;the currently selected feature. 
Second check, if there's an action defined in any of the hits with the currently 
selected feature declared as the dominant feature.</FONT></DIV>
<DIV><FONT size=2></FONT>&nbsp;</DIV>
<DIV><FONT size=2>2. Why&nbsp;a dominant feature?</FONT></DIV>
<DIV><FONT size=2>Yes, we could have split up all dependencies and listed them 
depending on the feature with the focus.</FONT></DIV>
<DIV><FONT size=2>However we wanted to design a compact structure, which groups 
related dependencies properly. If there are dependencies with three or more 
features involved, but different actions depending on which feature has the 
focus, we were concerned that listing all required combinations separately would 
confuse the reader and developer of the device description, especially, if the 
list is not properly ordered.</FONT></DIV>
<DIV><FONT size=2>And it narrows the number of candidates for the driver once it 
hits a FeatureCondition.</FONT></DIV>
<DIV><FONT size=2></FONT>&nbsp;</DIV>
<DIV><FONT size=2>3. Extended functionality.</FONT></DIV>
<DIV><FONT size=2>We wanted to support functionality commonly available in a 
number of contemporary driver concepts.</FONT></DIV>
<DIV><FONT size=2>This includes messages as well as hints for info 
buttons,&nbsp;mandatory selections of settings of features based on a dependency 
and indications that the appearance of a feature should change, once the 
dependency is resolved.</FONT></DIV>
<DIV><FONT size=2></FONT>&nbsp;</DIV>
<DIV><FONT size=2>4. Conversion between different concepts.</FONT></DIV>
<DIV><FONT size=2>We always have in mind that dependencies (sometimes called 
constraints) are defined differently in various concepts.</FONT></DIV>
<DIV><FONT size=2>We are positive that a conversion from or to UPDF is always 
possible and not ambiguous, although you may loose some functionality when 
converting to other standards.</FONT></DIV>
<DIV><FONT size=2></FONT>&nbsp;</DIV>
<DIV><FONT size=2>Check it out!</FONT></DIV>
<DIV><FONT size=2></FONT>&nbsp;</DIV>
<DIV><FONT size=2>Regards</FONT></DIV>
<DIV><FONT size=2>Norbert Schade</FONT></DIV>
<DIV><FONT size=2></FONT>&nbsp;</DIV>
<DIV><FONT size=2></FONT>&nbsp;</DIV>
<DIV><FONT size=2>Norbert Schade<BR>69 Prescott Drive<BR>North Chelmsford<BR>MA 
01863<BR>phone: 1-978-251-1017<BR>email: <A 
href="mailto:norbertschade@comcast.net">norbertschade@comcast.net</A></FONT></DIV></BODY></HTML>