Re: WIMS> RE: What name for Covers?

From: wamwagner@comcast.net
Date: Fri Oct 20 2006 - 16:53:20 EDT

  • Next message: Richard_Landau@Dell.com: "WIMS> CIM> Status of Phase 1 CRs: good."

    Rick,

    This was a long time ago, and there was discussion about it, but I think the thought was that there could be covers with sensors but not interlocks. That is, the machine could sense that a cover was open, but this did not prevent any operation. Similarly, there could be an internal interlock that was not directly associated with a cover.. perhaps something related to the presense or proper seating of a component.

    Perhaps, particularly in the smaller machines, this distinction is not significant in practice. I could see where just "interlock" should be quite sufficient for the projector group.

    Bill Wagner

    -------------- Original message --------------
    From: <Richard_Landau@Dell.com>

    My off-center read on the cover table = shabby naming. What is included here is the set of "covers and interlocks." Quoth the MIB, "The cover portion of the General print sub-unit describes the covers and interlocks of the printer. The Cover Table has an entry for each cover and interlock." However, the only covers that count are the ones with interlocks on them. No interlock sensor, no table entry. A door is a door only if it has an interlock sensor on it. All covers are interlocks, but not all interlocks are covers. The group should have been called interlocks in the first place. Flame off. :-)

    Thinking how one might implement an IsCover boolean property in a CIM-to-SNMP proxy agent, one would have to use the enum values {door,interlock} x {Open,Closed}, which the client can use anyway if we preserve the enums.

    Not a big deal. Maybe we'll flip a coin in Lexington. The projector group was not bound to the naming of the past, so Interlock group was an okay name. The description (attached, which I wrote for it, I admit), applies well to printers, I think, except perhaps for the word "projector."

    rick

    PS: If I can ever get to the ftp site, I will upload the amended spreadsheet, which says PrintDeviceCover.

    From: McDonald, Ira [mailto:imcdonald@sharplabs.com]
    Sent: Friday, October 20, 2006 12:46
    To: Landau, Richard
    Cc: wims@pwg.org
    Subject: RE: What name for Covers?

    Hi Rick,

    The Printer MIB did a bit of shabby modelling, because an Interlock
    may protect a part (e.g., pinch roller) that is NOT a Cover (I've seen
    MIB-walks of real printers that did this).

    Locations in MediaPaths are often instrumented with Interlock sensors,
    although the thing being moved/removed isn't always a cover.

    So, what about 'prtCoverTable' maps to 'PrintInterlock(s)', but
    with a good Description cause explaining the legacy Printer MIB
    modelling, and ADDING an 'IsCover' boolean property (defaults
    to 'false' of course) to disambiguate the two cases?

    Cheers,
    - Ira

    Ira McDonald (Musician / Software Architect)
    Blue Roof Music / High North Inc
    PO Box 221 Grand Marais, MI 49839
    phone: +1-906-494-2434
    email: imcdonald@sharplabs.com
    -----Original Message-----
    From: Richard_Landau@Dell.com [mailto:Richard_Landau@Dell.com]
    Sent: Friday, October 20, 2006 1:20 PM
    To: McDonald, Ira
    Cc: wims@pwg.org
    Subject: RE: What name for Covers?

    Gee, I thought that Cover included Interlock and that they were already thoroughly intertwined a decade ago by the TC that you cited. It's only the sensor that we care about, whether it's on a door or an internal component -- for instance, if there is a door without a sensor, it certainly would not appear in this group -- so I thought that interlock was the more general and inclusive term.
    ---------
    PrtCoverStatusTC ::= TEXTUAL-CONVENTION
        -- This TC was extracted from prtCoverStatus in RFC 1759.
        STATUS current
        DESCRIPTION
            "Values for encoding the state of a particular cover or
            access panel on the printer case or enclosure."
        SYNTAX INTEGER {
                      other(1),
                      coverOpen(3),
                      coverClosed(4),
                      interlockOpen(5),
                      interlockClosed(6)
                      }
    ---------
    But if the group wants PrintDeviceCovers, hey, I'm easy. Other opinions or suggestions?

    rick

    From: McDonald, Ira [mailto:imcdonald@sharplabs.com]
    Sent: Friday, October 20, 2006 11:56
    To: Landau, Richard
    Cc: 'wims@pwg.org'
    Subject: RE: What name for Covers?

    Hi Rick,

    [copied WIMS list to make others aware of these issues]

    A Cover is NOT an Interlock (in the Printer MIB) - the Interlock is just the
    sensor and logic.

    Conflating Cover with Interlock will screw up the semantics of some widely
    implemented existing values of 'PrtAlertCodeTC' as well.

    In the WIMS and Semantic Model/v2.0 schema Subunits.xsd, the classes
    are simply Cover(s).

    I dislike abandoning Printer MIB terms - how about 'PrintDeviceCover(s)'?

    Cheers,
    - Ira

    Ira McDonald (Musician / Software Architect)
    Blue Roof Music / High North Inc
    PO Box 221 Grand Marais, MI 49839
    phone: +1-906-494-2434
    email: imcdonald@sharplabs.com
    -----Original Message-----
    From: Richard_Landau@Dell.com [mailto:Richard_Landau@Dell.com]
    Sent: Friday, October 20, 2006 12:39 PM
    To: McDonald, Ira
    Subject: What name for Covers?

    I think that PrintCovers is a crummy name for a class. Almost everyone who did not grow up with PrinterMIB would misunderstand the class until they read the description. I suggest PrintInterlocks. In the Projector & Display Management group, we are calling the comparable stuff the Interlock Group. (If there isn't a sensor on the door, then we don't care about it.) Seem reasonable to use PrintInterlock as a classname instead?
    rick
    ----------------------
    Richard_Landau(at)dell(dot)com, Stds & System Mgt Arch, CTO Office
    +1-512-728-9023, One Dell Way, RR5-3, MS RR5-09, Round Rock, TX 78682

    --
    No virus found in this outgoing message.
    Checked by AVG Free Edition.
    Version: 7.1.408 / Virus Database: 268.13.9/490 - Release Date: 10/20/2006
    

    -- No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.1.408 / Virus Database: 268.13.9/490 - Release Date: 10/20/2006

    attached mail follows:





    This archive was generated by hypermail 2.1.4 : Fri Oct 20 2006 - 16:53:27 EDT