Possible bug in MOF 3.0.1 spec for empty qualiferValueArrayInitializer

[mikeclayton]

The MOF 3.0.1 spec doesn't allow for empty qualifier value arrays like "{}" in this property from the "MSMCAEvent_InvalidError" class in WinXpProSp3WMI.mof:

    [WmiDataId(3), ValueMap{}] uint32 Type;

The MOF 3.0.1 spec says this:

442 qualifierList = "[" qualifierValue *( "," qualifierValue ) "]"
443 qualifierValue = qualifierName [ qualifierValueInitializer /
444 qualiferValueArrayInitializer ]
445 qualifierValueInitializer = "(" literalValue ")"
446 qualiferValueArrayInitializer = "{" literalValue *( "," literalValue ) "}"

so a qualiferValueArrayInitializer has to contain at least one item.

Note - this is the same as the MOF 3.0.0 spec so it might not be a bug - it might just be that the System.Management.ManagementBaseObject.GetFormat method returns invalid MOF text for some classes, but we should provide an option to allow or disallow empty arrays via the ParserQuirks enum anyway.

[mikeclayton]

Posted to the DMTF Feedback form on 02/02/2019:

---

Hi,

I've found what I think is a bug in the Managed Object Format 3.0.1 spec here:

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

In section "7.4.1 QualifierList" there's a definition for qualiferValueArrayInitializer which does not allow for empty arrays:

442 qualifierList = "[" qualifierValue *( "," qualifierValue ) "]"
443 qualifierValue = qualifierName [ qualifierValueInitializer /
444 qualiferValueArrayInitializer ]
445 qualifierValueInitializer = "(" literalValue ")"
446 qualiferValueArrayInitializer = "{" literalValue *( "," literalValue ) "}"

which means that there must be at least one literalValue in the qualiferValueArrayInitializer.

In which case, the following property declaration is invalid:

[Values{}] string HostingModel;

Note that other array definitions elsewhere allow for empty arrays, e.g.:

771 complexValueArray = "{" [ complexValue *( "," complexValue) ] "}"

The additional "[ ... ]" means the array can be empty.

Could you confirm whether the qualiferValueArrayInitializer definition should allow empty arrays? E.g.

446 qualiferValueArrayInitializer = "{" [ literalValue *( "," literalValue ) ] "}"

Thanks,

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 mike@kingslandconsulting.co.uk
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 mike@kingslandconsulting.co.uk
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...