Possible bug in MOF 3.0.1 spec for enumValueArray using enumNames

[mikeclayton]

The section "7.6.3 Enum type value" of the MOF spec 3.0.1 defines a syntax element "enumValueArray" as follows:

7.6.3 Enum type value

941 enumTypeValue = enumValue / enumValueArray
942 enumValueArray = "{" [ enumName *( "," enumName ) ] "}"
943 enumValue = [ enumName "." ] enumLiteral
944 enumLiteral = IDENTIFIER

What this means is that the enumValue rule allows a single enum value to be fully qualified or omit the enum type name - e.g.:

Single enum value - unqualified

instance of GOLF_Date
 {
     Year = 2011;
     Month = July;
     Day = 31;
 };

or

Single enum value - fully qualified

instance of GOLF_Date
 {
     Year = 2011;
     Month = MonthEnum.July;
     Day = 31;
 };

(note "July" vs "MonthEnum.July")

but the enumValueArray rule an array does not allow fully qualified enum values, so this is valid:

Enum value array - unqualified

instance of MY_Class
 {
     Months = { January, April, June, September };
 };

but this is not:

Enum value array - fully qualified

instance of MY_Class
 {
     Months = { MonthEnum.January, MonthEnum.April, MonthEnum.June, MonthEnum.September };
 };

I suspect the enumValueArray rule should be as follows:

enumValueArray = "{" [ enumValue *( "," enumValue ) ] "}"

i.e. an array of enumValues rather than the current array of enumNames.

Choices are:

• Implement the spec as-is and potentially be incompatible with MOF files that fully qualify enum array values

• Use enumValueArray = "{" [ enumValue *( "," enumValue ) ] "}" and override the spec, but potentially parse MOF files that don't adhere to the strict standard

• Implement a ParserQuirks class that lets us define the behaviour of this (and other quirks) at runtime

[mikeclayton]

Posted to the DMTF Feedback form on 14/01/2019:

---

Hi,

I think I've found an error in your Managed Object Format specification 3.0.1 here:

https://www.dmtf.org/sites/default/files/standards/documents/DSP0221_3.0.1.pdf

At line 942, the "enumValueArray" rule is defined as:

941 enumTypeValue = enumValue / enumValueArray
942 enumValueArray = "{" [ enumName *( "," enumName ) ] "}"
943 enumValue = [ enumName "." ] enumLiteral
944 enumLiteral = IDENTIFIER

I think line 942 should read:

942 enumValueArray = "{" [ enumValue *( "," enumValue ) ] "}"

i.e. an enumValueArray contains a list of enumValues, not enumNames.

Otherwise as it stands at present an enumValue is the (optionally fully qualified) name of an enum value - e.g.

instance of GOLF_Date
 {
     Year = 2011;
     Month = July;
     Day = 31;
 };

or

instance of GOLF_Date
 {
     Year = 2011;
     Month = MonthEnum.July;
     Day = 31;
 };

whereas items in an enumValueArray can never contain fully qualified items.

E.g, this is valid:

instance of MY_Class
 {
     Months = { January, April, June, September };
 };

but this is not:

instance of MY_Class
 {
     Months = { MonthEnum.January, MonthEnum.April, MonthEnum.June, MonthEnum.September };
 };

which is inconsistent with the ability to fully-quailify a single enumValue.

Maybe that's the intention, but my suspicion is the specification document contains a typo in 942 which should read enumValue where it currently reads enumName as described above.

If it's not the case, perhaps the documentation could be updated to make it clearer why a single item has to be an enumValue but an array has to contain enumNames.

I hope this helps.

Cheers,

Mike

---

[mikeclayton]

Response from DMTF taskforce a year ago (forgot to post it before!):

---

From: Michael [redacted] <[redacted]@yahoo.com>
Sent: 01 April 2019 21:55
To: Mike Clayton [email protected]
Cc: Robert [redacted] <robert@[redacted]>; Hemal [redacted] hemal.[redacted]@[redacted]>
Subject: Your submissions to the DMTF Feedback portal on DSP0221 version 3.0.1

Mike,

I have reviewed your submissions and I believe you are correct. I also had
the author of DSP0221 and his initial take is that your changes look correct.

However, DSP0221 is the MOF spec for CIM Version 3. To our knowledge, there
are no implementations of CIM Version 3. If you want to work with CIM Version 2,
you should be looking at the MOF specifications in DSP0004 version 2.8.0.

Note that work on CIM Version 3 has stopped. The only CIM Schema we publish
and maintain is a CIM Version 2 schema.

Michael [redacted]
Chair of the Schema Task Force

---

Reply:

---

From: Mike Clayton [email protected]
Sent: 03 April 2019 20:39
To: Michael [redacted] <[redacted]@yahoo.com>
Cc: Robert [redacted] <robert@[redacted]>; Hemal [redacted]<hemal.[redacted]@[redacted]>
Subject: RE: Your submissions to the DMTF Feedback portal on DSP0221 version 3.0.1

Hi Michael,

Thanks for the review of the submissions, and for the additional background about DSP0221.

For what it's worth, DSP0221 seems like a much more detailed and comprehensive description of the MOF format than in DSP0004 (notwithstanding the differences in the actual spec) - it'd be great to see the structure and detail of DSP0221 retro-fitted back into DSP0004 at some point in the future (or maybe split out of DSP0004 as an auxiliary document for CIMV2).

Incidentally, if you ever need a reference implementation of a strict parser for the (now deprecated) MOF 3.0.1 spec I've been spending quite a lot of time on this GitHub project which is how I found the issues with DSP0221 v 3.0.1 in the first place...

https://github.com/KingslandConsulting/Kingsland.MofParser

It's got some backward compatibility options for CIMV2 so it's not totally dead in the water now, but based on what you've said about DSP0221 it looks like I might need to do a bit of work to get it strictly compatible with DSP0004 :-).

Thanks again,

Mike

---

I'll leave this ticket open to flag up the issues with the spec, but it doesn't look like it'll be fixed any time soon...