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
ftp://ftp.pwg.org/pub/pwg/wims/cim/Visio-Printer_12.pdf
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
>http://www.dmtf.org/apps/org/workgroup/cim-core/download.php/32786/Vis> io-Printer_12.pdf
>> 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
>-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.pwg.org/archives/wims/attachments/20070823/ef808a89/attachment.html