The next WIMS CIM conference call is at 2 PM EST, Thursday 9 November.
Dial In: 1-866-365-4406
Toll #: 1-303-248-9655
Passcode: 2635888#
Ira and Rick pointed out some subjects for discussion last week, including:
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.
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.)
2. Pete’s observation about prtInputMaxCapacity suggested that it might need to reflect different paper thickness. There is some discussion needed on this.
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)
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.)
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 there was consensus on this. Note that Ira appears to have a different take on this, suggesting:
“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).â€
I suggest that this should have some discussion.
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: . . ftp://ftp.pwg.org/pub/pwg/wims/schema/WimsType-20060612.xsd used, e.g., in element 'InputTrayMaxCapacityBasis' defined in: ftp://ftp.pwg.org/pub/pwg/wims/schema/Subunits-20060612.xsd
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).
d. Returning to where we were before the face to face, Rick may have pictures of the class hierarchy, and maybe one example of instances (?)
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.
Bill Wagner, Chairman, WIMS/PWG
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.pwg.org/archives/wims/attachments/20061108/c3415c89/attachment.html