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> 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. Yay. </FONT></P>
<P><FONT SIZE=2 FACE="Arial">There was a question about cardinality. 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. I updated the two CRs with the issue and response, resubmitted them to DMTF, and reposted them to the WIMS-CIM FTP site. </FONT></P>
<P><FONT SIZE=2 FACE="Arial">Also, he (Crandall) did not understand that Finisher is optional while MediaPath and OutputTray are mandatory. We perhaps did not make that sufficiently explicit in the modeling, and he thinks we should. 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. </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. For the optional subunits (Interlock, Finisher, ConsoleLight, Supply), we can use simply CIM_Component. </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. 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. (Yes, eventually, we will learn all the rules.) If we wish, we can withdraw these anytime before they are voted on in TC; we have at least a week to decide. My thought: sure, why not. If we don't need more specific classes, let's not define them. I will be happy to redraw the class diagram. </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 & 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>