attachment

<html><body> <DIV>The next WIMS CIM conference call is at <?xml:namespace prefix = st1 ns = "urn:schemas-microsoft-com:office:smarttags" /><st1:time Hour="14" Minute="0">2 PM EST</st1:time>, Thursday 9 November.</DIV> <DIV> <DIV>Dial In: 1-866-365-4406 Toll #: 1-303-248-9655 Passcode: 2635888# </DIV></DIV> <DIV><PRE><?xml:namespace prefix = o ns = "urn:schemas-microsoft-com:office:office" /><o:p> </o:p>Ira and Rick pointed out some subjects for discussion last week, including:</PRE><PRE><o:p> </o:p>a.       Review of minutes ftp://ftp.pwg.org/pub/pwg/wims/minutes/06OCT-Lexington-WIMS-CIM-face-to-face.pdf The following comments have been noted  and apparently the minutes have been updated.<o:p></o:p></PRE><PRE style="MARGIN-LEFT: 0.25in"></PRE> 1.      To represent tables in CIM, using the strategy that we are proposing first, requires (2*n+1) objects to represent a table containing (n) rows.  (Not one row as stated.)<o:p></o:p> 2.      Pete’s observation about prtInputMaxCapacity suggested that it might need to reflect different paper thickness. There is some discussion needed on this.<o:p></o:p> 3.      Chris Story's concern was the inadequacy of the current prtConsoleDisplayBufferTable to represent *graphical* displays, not just "larger displays" (I seem to recall a question about touch screens as well)<o:p></o:p> 4.      The lack of enthusiasm of the industry at large to develop comprehensive management standards for multi-function devices entailed a long discussion and , if recorded and published, might maybe perhaps evoke a response from interested parties.)  <o:p></o:p> <o:p> </o:p> b.  prtInputMaxCapacity question as it relates to MIB and to CIM  Rick observed that Pete asked if max capacity is mutable, for example, if it changes when the weight of the paper changes.  The consensus of the group was that max capacity does not change in response to the media loaded.  It is a declaration by the vendor about the size (capacity) of the tray; it is not a value that is sensed by the printer.  Although I personally agree with Rick’s suggestion, I am not certain that t here was consensus on this.  Note that Ira appears to have a different take on this, suggesting:<o:p></o:p> “There is a  modeling error in Printer MIB, because the DESCRIPTION of 'prtInputMaxCapacity' says:   "...There is no convention associated with the media itself so this value reflects claimed capacity.  If this input sub-unit can reliably sense this value,  the value is sensed by the printer and may not be changed by  management requests; otherwise, ..." but it SHOULD be mutable, because 'prtInputCurrentLevel' is clearly intended to reflect real loaded media level. Ira urges that we repair '...MaxCapacity' throughout and change it to be SHOULD reflect loaded media (unless that can't be sensed - note that all 'prtInputMediaXxx' objects would then also be meaningless).”<o:p></o:p><PRE style="MARGIN-LEFT: 0.5in"><o:p></o:p></PRE><PRE>I suggest that this should have some discussion.<o:p></o:p></PRE><PRE><o:p> </o:p>c.    Ira also suggests that: . our_ (unspecified) solution to mapping Printer MIB counter out-of-band values into CIM properties is a cogent topic - see the type 'ObjectCounterBasisWKV' defined in:  .     . <A href="ftp://ftp.pwg.org/pub/pwg/wims/schema/WimsType-20060612.xsd">ftp://ftp.pwg.org/pub/pwg/wims/schema/WimsType-20060612.xsd</A> used, e.g., in element 'InputTrayMaxCapacityBasis' defined in:   ftp://ftp.pwg.org/pub/pwg/wims/schema/Sub units-20060612.xsd<o:p></o:p></PRE><PRE style="MARGIN-LEFT: 0.25in"><o:p> </o:p>Our modeling solution to the above is independent of what class hierarchy we adopt . (and I need the answer for my MIB to MOF translator code work).<o:p></o:p></PRE><PRE style="MARGIN-LEFT: 0.25in"><o:p></o:p></PRE><PRE style="MARGIN-LEFT: 0.25in; TEXT-INDENT: -0.25in; mso-list: l0 level1 lfo2; tab-stops: list .25in left 45.8pt 91.6pt 137.4pt 183.2pt 229.0pt 274.8pt 320.6pt 366.4pt 412.2pt 458.0pt 503.8pt 549.6pt 595.4pt 641.2pt 687.0pt 732.8pt">d.       </S PAN>Returning to where we were before the face to face, Rick may have pictures of the class hierarchy, and maybe one example of instances (?)<o:p></o:p></PRE><PRE><o:p> </o:p>e.       And Ira has also suggested follow-up discussion of the WIMS "Counter Issue" which has wider . implications, including Pete's plan to use XML _attribute_ rather than XML _element_ for the . Printer MIB out-of-band values in counters, which were modeled as XML _element_ in my . Subunits schema and would be CIM _property_ and not CIM _qualifier_ in any plausible CIM . mapping of Printer MIB.</PRE><PRE>Bill Wagner, Chairman, WIMS/PWG</PRE><PRE><o:p></o:p> </PRE> <o:p> </o:p></DIV></body></html>