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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.pwg.org/archives/wims/attachments/20070817/fe304dcb/attachment.html