From: Richard_Landau@Dell.com
Date: Fri Sep 21 2007 - 17:35:51 EDT
Ira, et al.,
Good news and bad news from Core today.
Bad news: Neither CR passed the first ballot.
Good news: We want to withdraw one of them anyway, and we have clear
guidance about how to get the other one passed.
CIM_PrintAlertLog:
- One issue: why not just use the base class? Good idea. Ira and I had
already discussed using the base class directly before we submitted this
CR. We will withdraw this one and use the base class (CIM_RecordLog)
instead. (Already withdrawn.)
If we wish to preserve the MappingString to prtAlertTable, then we can
add this to the base class. It was asserted that this addition would
not be unprecedented, though I have not tripped over any examples.
John Crandall noted that there should be a naming convention for logs
rather than a proliferation of subclasses. Good idea. I will propose
something to Core or Server Management.
CIM_PrintAlertRecord:
Issue: Why not use RecordData instead of defining LocalizedDescription?
A fair question. We do intend to put a lot of data into RecordData, but
we have not specified it yet, and we don't want to leave writing
something down until we write a Printer Profile, several quarters from
now.
Question: Would it be reasonable for us to insert into the Description
of RecordFormat a list of the data we intend to publish in there?
Answer: Yes, you can override the Description of RecordFormat or
RecordData to describe what you plan to put in there, in advance of a
formal profile.
We need to discuss what fields we want to put into the RecordData and
what we want to say about them. For instance, we could include a SHALL
list and a MAY list of fields, and for each field, give a very short
definition and maybe the mapping string to prtAlertXxx. And do we wish
to move any other fields that are currently broken out into the
RecordData string? (My vote: no, unless forced to do so.)
Another issue will come up eventually, and that is when do we add the
list of alert codes to the CIM Message Registry? And how? I will argue
that we ought to be assigned a region in which the mapping of IANA
printer alert codes to CIM message number can be calculated. Later.
Issue: Why not associate to the actually element instead of defining
ComponentClassName/ComponentElementName? Answer: The alert record is a
static object, recorded at some time in the past. It is intended to
capture a snapshot of the condition as it was at that time. The state
of the device is not necessarily the same as it was back then, and it
might not be possible to form sensible associations. Result: Good
reason. Say that in the next draft.
Overall, given the rethinking and rewording necessary, we will have to
deal with this CR next week. I will start work on the last couple
classes, too, Interlocks and ConsoleLights, and we'll try to submit all
three next Friday.
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
This archive was generated by hypermail 2.1.4 : Fri Sep 21 2007 - 17:36:01 EDT