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"> <TITLE>CIM> Status of CRs in Core: passed. And new news.</TITLE> <META content="MSHTML 6.00.2800.1595" name=GENERATOR></HEAD> <BODY> <DIV><SPAN class=449482818-19082007><FONT face=Arial color=#0000ff size=4>Hi Rick,</FONT></SPAN></DIV> <DIV><SPAN class=449482818-19082007><FONT face=Arial color=#0000ff size=4></FONT></SPAN> </DIV> <DIV><SPAN class=449482818-19082007><FONT face=Arial color=#0000ff size=4>About this PrinterComponent usage - NONE of our association MOFs use</FONT></SPAN></DIV> <DIV><SPAN class=449482818-19082007><FONT face=Arial color=#0000ff size=4>the PrinterComponent association - they ALL use CIM_Dependency (which</FONT></SPAN></DIV> <DIV><SPAN class=449482818-19082007><FONT face=Arial color=#0000ff size=4>is correct CIM usage).  Only the CIM_Printer to subunit association would be</FONT></SPAN></DIV> <DIV><SPAN class=449482818-19082007><FONT face=Arial color=#0000ff size=4>affected.  That is, CIM_AssociatedMediaPath has nothing to do with </FONT></SPAN></DIV> <DIV><SPAN class=449482818-19082007><FONT face=Arial color=#0000ff size=4>PrinterComponent - it references PrinterElement (the data class) via</FONT></SPAN></DIV> <DIV><SPAN class=449482818-19082007><FONT face=Arial color=#0000ff size=4>CIM_PrintMediaPath.</FONT></SPAN></DIV> <DIV><SPAN class=449482818-19082007><FONT face=Arial color=#0000ff size=4></FONT></SPAN> </DIV> <DIV><SPAN class=449482818-19082007><FONT face=Arial color=#0000ff size=4>Choosing only the mandatory subunits is a slippery slope - it means that</FONT></SPAN></DIV> <DIV><SPAN class=449482818-19082007><FONT face=Arial color=#0000ff size=4>a Printer MIB v3 can't make more subunits mandatory (which is indeed</FONT></SPAN></DIV> <DIV><SPAN class=449482818-19082007><FONT face=Arial color=#0000ff size=4>plausible) and be easily reflected in the CIM model.</FONT></SPAN></DIV> <DIV><SPAN class=449482818-19082007><FONT face=Arial color=#0000ff size=4></FONT></SPAN> </DIV> <DIV><SPAN class=449482818-19082007><FONT face=Arial color=#0000ff size=4>Cheers,</FONT></SPAN></DIV> <DIV><SPAN class=449482818-19082007><FONT face=Arial color=#0000ff size=4>- Ira</FONT></SPAN></DIV> <DIV><SPAN class=449482818-19082007><FONT face=Arial color=#0000ff size=4></FONT></SPAN> </DIV> <DIV><FONT face=Arial color=#0000ff size=4></FONT> </DIV> <P><FONT size=2>Ira McDonald (Musician / Software Architect)<BR>Chair - Linux Foundation Open Printing WG<BR>Blue Roof Music / High North Inc<BR>PO Box 221  Grand Marais, MI  49839<BR>phone: +1-906-494-2434<BR>email: imcdonald@sharplabs.com</FONT> </P> <DIV class=OutlookMessageHeader dir=ltr align=left><FONT face=Tahoma size=2>-----Original Message-----<BR><B>From:</B> owner-wims@pwg.org [mailto:owner-wims@pwg.org]<B>On Behalf Of </B>Richard_Landau@Dell.com<BR><B>Sent:</B> Friday, August 17, 2007 5:34 PM<BR><B>To:</B> wims@pwg.org<BR><B>Subject:</B> WIMS> CIM> Status of CRs in Core: passed. And new news. <BR><BR></FONT></DIV> <P><FONT face=Arial size=2>The two CRs that were balloted this week, AssociatedPrintOutputTray and AssociatedPrintMediaPath, will be forwarded to TC.  Yay.  </FONT></P> <P><FONT face=Arial size=2>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 face=Arial size=2>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 face=Arial size=2>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 face=Arial size=2>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 face=Arial size=2>rick</FONT> <BR><FONT face=Arial size=2>----------------------</FONT> <BR><FONT face=Arial size=2>Richard_Landau(at)dell(dot)com, Stds & System Mgt Architecture, CTO Office</FONT> <BR><FONT face=Arial size=2>+1-512-728-9023, One Dell Way, RR5-3, MS RR5-09, Round Rock, TX 78682</FONT> </P></BODY></HTML> <BR> <P><FONT SIZE=2>No virus found in this outgoing message.<BR> Checked by AVG Free Edition.<BR> Version: 7.5.484 / Virus Database: 269.12.0/961 - Release Date: 8/19/2007 7:27 AM<BR> </FONT> </P>