Hi,
Forwarded to WIMS WG list for those who don't see Steering Committee.
Cheers,
- Ira
Ira McDonald (Musician / Software Architect)
Chair - Linux Foundation Open Printing WG
Blue Roof Music / High North Inc
PO Box 221 Grand Marais, MI 49839
phone: +1-906-494-2434
email: imcdonald at sharplabs.com
-----Original Message-----
From: owner-sc at pwg.org [mailto:owner-sc at pwg.org]On Behalf Of Richard_Landau at Dell.com
Sent: Friday, August 10, 2007 4:31 PM
To: sc at pwg.org
Subject: SC> Date: Fri, 10 Aug 2007 16:30:03 -0500
Good news everywhere, for a change.
Status of CRs after CIM Core call this morning:
- Six passed thru the new verifier tool -- *and* the additional secret handshake test for color purity (story later) -- and therefore passed out of Core. They will now be balloted at TC.
- Two passed all the tests and need to be reballoted at Core. Everyone was on vacation during the last ballot cycle and they did not receive enough attention (or votes).
I'm tired of typing today. Please check the wiki page for the latest status:
HYPERLINK "http://pwg-wiki.wikispaces.com/DMTF+CIM+Core+Schema+Change+Requests"http://pwg-wiki.wikispaces.com/DMTF+CIM+Core+Schema+Change+Requests
On the subject of our enumerated values for Other and Unknown, we won that one, too. Ira did some research on relative inconsistencies in existing CIM and such, and I sent several strongly worded messages to Crandall and Hass. Got me on the agenda, anyway. At the meeting the topic was discussed at some length. Turns out that there has been a new convention starting about three years ago to use the values 0=Unknown and 1=Other. It is not yet written down. A new Core White Paper stating such rules and conventions is in draft, and this will be added. The new rule is something like this:
- If enumerated values come directly from an existing spec, the proposing group should be permitted to use the values directly, if they wish, without remapping.
BTW, IETF/SNMP rules don't count for much here, because CIM has an explicit way to signify NULL and SNMP doesn't; so zero is not a forbidden value in CIM.
Now we can get back to work.
rick
PS: Story on the color purity test. In the MOF text of a CR, added text must be blue, deleted text must be red, and unchanged text must be black. The new automated build procedures actually use the text color to guide (from the HTML CR file) updating the MOF text in the database. However, there are several ways to tag text color, and most HTML editors use a style that the automated procedures don't like. So some of the editing has to be done with a specific editor, and carefully at that, or by a post-editing processing step. (Personally, I used my old pal sed.)
If that weren't bad enough, the new CR-lint verifier tool has a bug in it that doesn't flag improper tags with an explicit error message. So *everyone* stepped in this bear trap, including some of the working group chairpeople.
We *are* sneaking up on a solution. Really.
----------------------
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
No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.5.476 / Virus Database: 269.11.11/944 - Release Date: 8/9/2007 2:44 PM
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.pwg.org/archives/wims/attachments/20070810/d83dfb3c/attachment.html