attachment

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"> <HTML><HEAD><TITLE>CIM> Status of CRs in Core: passed. And new news.</TITLE> <META http-equiv=Content-Type content="text/html; charset=us-ascii"> <META content="MSHTML 6.00.2900.3157" name=GENERATOR></HEAD> <BODY> <DIV dir=ltr align=left> Wow, I must have been more unclear than usual.  I managed to confuse the issue completely.  Sorry.  Blame it on Friday.  I was trying to suggest relaxing a number of associations, particularly CIM_PrinterComponent, but only in the places where it is currently used, not new locations.  <?xml:namespace prefix = o ns = "urn:schemas-microsoft-com:office:office" /><o:p> </o:p> The changes I am suggesting are these: <o:p> </o:p> 1.  Add the MIN(1) cardinality to the subunit side of the CIM_PrinterComponent association.  <o:p> </o:p> 2.  Use this association only between CIM_Printer and the mandatory subunits of a Printer.  Our class diagram already states exactly which of the subunits have minimum cardinality one: InputTray, OutputTray, MediaPath, Marker, Channel, and Interpreter.  <o:p> </o:p> (Note that AlertLog by convention uses a different association to Printer.)  (Also note that, erroneously, I have PrinterSettingData marked as cardinality one, too; I will fix that.  It also uses a different association by convention.)  <o:p> </o:p> 3.  For the other subunits, where the minimum cardinality is zero, relax the model's association between CIM_Printer and the subunit to CIM_Dependency.  That is, use CIM_Dependency between CIM_Printer and the optional subunits: Interlock, Supply, Finisher, and ConsoleLight.  <o:p> </o:p> 4.  If in the future someone were to make another subunit mandatory that is currently optional, one could change the association between CIM_Printer and the subunit to CIM_PrinterComponent.  Since CIM_Dependency is the parent class of CIM_PrinterComponent, this is a legal change in CIM : no semantics are lost and additional semantics are gained by using the subclass instead of the parent.  <o:p> </o:p> 5.  The two proposed associations between Finisher and MediaPath and OutputTray are currently trivial subclasses of CIM_Depencency.  Relax the model's associations to CIM_Dependency, the parent class, since no semantic value is gained by trivially subclassing this class.  <o:p> </o:p> 6.  If we decide to to #5, then we can withdraw the CRs to create these two new associations before they get to TC for vote.  <o:p> </o:p> Boy, I hope that's clearer.  Again, I apologize for the over-abbreviated and confusing message.  <o:p> </o:p> rick <o:p></o:p> </DIV> <DIV class=OutlookMessageHeader lang=en-us dir=ltr align=left> <HR tabIndex=-1> From: McDonald, Ira [mailto:imcdonald@sharplabs.com] Sent: Sunday, August 19, 2007 12:34 To: Landau, Richard; wims@pwg.org Subject: RE: WIMS> CIM> Status of CRs in Core: passed. And new news. </DIV> <DIV></DIV> <DIV>Hi Rick,</DIV> <DIV> </DIV> <DIV>About this PrinterComponent usage - NONE of our association MOFs use</DIV> <DIV>the PrinterComponent association - they ALL use CIM_Dependency (which</DIV> <DIV>is correct CIM usage).  Only the CIM_Printer to subunit association would be</DIV> <DIV>affected.  That is, CIM_AssociatedMediaPath has nothing to do with </DIV> <DIV>PrinterComponent - it references PrinterElement (the data class) via</DIV> <DIV>CIM_PrintMediaPath.</DIV> <DIV> </DIV> <DIV>Choosing only the mandatory subunits is a slippery slope - it means that</DIV> <DIV>a Printer MIB v3 can't make more subunits mandatory (which is indeed</DIV> <DIV>plausible) and be easily reflected in the CIM model.</DIV> <DIV> </DIV> <DIV>Cheers,</DIV> <DIV>- Ira</DIV> <DIV> </DIV> <DIV> </DIV> Ira McDonald (Musician / Software Architect) Chair - Linux Foundation Open Printing WG Blue Roof Music / High North Inc PO Box 221  Grand Marais, MI  49839 phone: +1-906-494-2434 email: imcdonald@sharplabs.com <DIV class=OutlookMessageHeader dir=ltr align=left>-----Original Message----- From: owner-wims@pwg.org [mailto:owner-wims@pwg.org]On Behalf Of Richard_Landau@Dell.com Sent: Friday, August 17, 2007 5:34 PM To: wims@pwg.org Subject: WIMS> CIM> Status of CRs in Core: passed. And new news. </DIV> The two CRs that were balloted this week, AssociatedPrintOutputTray and AssociatedPrintMediaPath, will be forwarded to TC.  Yay.  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.  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.  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.  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.  rick ---------------------- Richard_Landau(at)dell(dot)com, Stds & System Mgt Architecture, CTO Office +1-512-728-9023, One Dell Way, RR5-3, MS RR5-09, Round Rock, TX 78682 No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.5.484 / Virus Database: 269.12.0/961 - Release Date: 8/19/2007 7:27 AM </BODY></HTML>