attachment

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=us-ascii">
<META NAME="Generator" CONTENT="MS Exchange Server version 6.5.7652.24">
<TITLE>CIM&gt; Status of CRs in Core: passed.  And new news.   </TITLE>
</HEAD>
<BODY>
<!-- Converted from text/rtf format -->

<P><FONT SIZE=2 FACE="Arial">The two CRs that were balloted this week, AssociatedPrintOutputTray and AssociatedPrintMediaPath, will be forwarded to TC.&nbsp; Yay.&nbsp; </FONT></P>

<P><FONT SIZE=2 FACE="Arial">There was a question about cardinality.&nbsp; I conferred with Ira and responded that the relationships between Finisher and MediaPath (and OutputTray) are many-to-many, so cardinality need not be specified.&nbsp; I updated the two CRs with the issue and response, resubmitted them to DMTF, and reposted them to the WIMS-CIM FTP site.&nbsp; </FONT></P>

<P><FONT SIZE=2 FACE="Arial">Also, he (Crandall) did not understand that Finisher is optional while MediaPath and OutputTray are mandatory.&nbsp; We perhaps did not make that sufficiently explicit in the modeling, and he thinks we should.&nbsp; The Visio diagram is clear about cardinalities, but we should make it clearer in the association MOFs that some components are required and others are optional.&nbsp; </FONT></P>

<P><FONT SIZE=2 FACE="Arial">For example, we should add MIN(1) to the CIM_PrinterComponent association and then use that for only the mandatory subunits.&nbsp; For the optional subunits (Interlock, Finisher, ConsoleLight, Supply), we can use simply CIM_Component.&nbsp; </FONT></P>

<P><FONT SIZE=2 FACE="Arial">And he asked why we are doing these specific associations at all if they do not contain any additional semantics.&nbsp; He feels that we could use plain old CIM_Dependency (from which these two are subclassed) if there is no additional information: no new properties, no new cardinality restrictions.&nbsp; (Yes, eventually, we will learn all the rules.)&nbsp; If we wish, we can withdraw these anytime before they are voted on in TC; we have at least a week to decide.&nbsp; My thought: sure, why not.&nbsp; If we don't need more specific classes, let's not define them.&nbsp; I will be happy to redraw the class diagram.&nbsp; </FONT></P>
<BR>

<P><FONT SIZE=2 FACE="Arial">rick</FONT>

<BR><FONT SIZE=2 FACE="Arial">----------------------</FONT>

<BR><FONT SIZE=2 FACE="Arial">Richard_Landau(at)dell(dot)com, Stds &amp; System Mgt Architecture, CTO Office</FONT>

<BR><FONT SIZE=2 FACE="Arial">+1-512-728-9023, One Dell Way, RR5-3, MS RR5-09, Round Rock, TX 78682</FONT>
</P>

</BODY>
</HTML>