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> Note to CIM Core chairs re planned changes to printer model. </TITLE> </HEAD> <BODY>  An early warning to Crandall and Hass that we are changing the CIM representation slightly to model more faithfully the actual conformance requirements of Printer MIB.  The new Visio diagrams are posted in <A HREF="ftp://ftp.pwg.org/pub/pwg/wims/cim/Visio-Printer_12.pdf">ftp://ftp.pwg.org/pub/pwg/wims/cim/Visio-Printer_12.pdf</A> rick ______________________________________________ From:   Landau, Richard  Sent:   Thursday, August 23, 2007 18:06 To:     'John Crandall'; Hass, Jon Subject:        Please confirm that you agree with planned changes to printer model.  John and Jon, After our discussions about the printer classes in ballot, the PWG group decided to make some changes in the model to address your concerns.  I have posted an updated Visio diagram of the class structures in <A HREF="http://www.dmtf.org/apps/org/workgroup/cim-core/download.php/32786/Visio-Printer_12.pdf">http://www.dmtf.org/apps/org/workgroup/cim-core/download.php/32786/Visio-Printer_12.pdf</A> To address the question of cardinalities for required elements of a printer, we plan a number of minor changes.  1.  Add the MIN(1) cardinality to the subunit side of the CIM_PrinterComponent association to indicate that at least one subunit is required by this association.  2.  Use the CIM_PrinterComponent association *only* between CIM_Printer and the mandatory subunits of a Printer.  I have revised the class diagram to state explicitly which of the subunits have minimum cardinality one: InputTray, OutputTray, MediaPath, Marker, Channel, and Interpreter.  (Note that AlertLog by convention uses a different association to Printer, mandated by its Profile.)  3.  For the other subunits, where the minimum cardinality is zero, relax the model's association between CIM_Printer and the subunit to CIM_ConcreteComponent.  That is, use CIM_ConcreteComponent between CIM_Printer and the optional subunits: Interlock, Supply, Finisher, and ConsoleLight.  4.  If in the future someone were to make another subunit mandatory that is currently optional, then one could change the association between CIM_Printer and the subunit from CIM_ConcreteComponent to CIM_PrinterComponent.  Since CIM_Component is the parent class of CIM_PrinterComponent, I believe that this would be a legal change in CIM: no semantics are lost and additional semantics are gained by using the subclass instead of the parent.  Also, you suggested that we consider dropping the associations CIM_AssociatedPrintMediaPath and CIM_AssociatedPrintOutputTray.  5.  The two proposed associations between Finisher and MediaPath and OutputTray are currently trivial subclasses of CIM_Dependency.  Instead, use the CIM_Dependency association, the parent class, since no semantic value is gained by trivially subclassing this class.  6.  As a consequence of #5, we wish to withdraw these two CRs, numbers 965 and 966.  Please confirm that you agree with these planned changes.  And, if you agree, please withdraw the two CRs as specified in #5 and #6.  Thanks, John and Jon.  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 </BODY> </HTML>