Possible bug in MOF 3.0.1 spec for complexValue using INSTANCE OF

[mikeclayton]

The MOF Spec 3.0.0 defines a rule for complexValue as follows:

A.1 Value definitions

complexValue = ( INSTANCE / VALUE ) OF
               ( structureName / className / associationName )
               [ alias ] propertyValueList

which changed to the following in the MOF Spec 3.0.1:

7.5.9 Complex type value

complexValue = aliasIdentifier /
               ( VALUE OF
                 ( structureName / className / associationName )
                 propertyValueList )

Both versions of the spec have an example MOF JohnDoe.mof as follows:

E.20 JohnDoe.mof / D.20 JohnDoe.mof

instance of GOLF_ClubMember
{
    Caption = "Instance of John Doe\'s GOLF_ClubMember object"; 
    FirstName = "John"; 
    LastName = "Doe"; 
    Status = Basic; 
    MembershipEstablishedDate = $JohnDoesStartDate; 
    MonthlyFee = 250.00; 
    LastPaymentDate = instance of GOLF_Date 
    {
        Year = 2011; 
        Month = July; 
        Day = 31; 
    }; 
    MemberAddress = value of GOLF_Address 
    { 
        State = IL; 
        City = "Oak Park"; 
        Street = "Oak Park Av."; 
        StreetNo = "1177; 
        ApartmentNo = "3B"; 
    };
    MemberPhoneNo = $JohnDoesPhoneNo; 
    MemberEmailAddress = "JonDoe@hotmail.com"; 
};

Note that LastPaymentDate uses instance of GOLF_Date, and MemberAddress uses value of GOLF_Address.

Both instance of and value of are valid in MOF Spec 3.0.0 (complexValue = ( INSTANCE / VALUE ) OF ..., but only value of is valid in the MOF Spec 3.0.1 (complexValue = aliasIdentifier / VALUE OF ...).

Either the JohnDoe.mof sample is wrong in the MOF 3.0.1 spec and LastPaymentDate should use value of (or an aliasIdentifier instead), or the definition of complexValue needs to allow instance of.

Choices are:

• Implement the MOF 3.0.1 spec as-is and potentially be incompatible with MOF files that use instance of in property values

• Allow instance of in property values, 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 a small problem with the MOF 3.0.1 spec here:

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

In the examples section "D.20 JohnDoe.mof" in Annex D there's a sample MOF file which contains the following:

1605 instance of GOLF_ClubMember
 1606 {
 ...
 1613 LastPaymentDate = instance of GOLF_Date
 1614 {
 1615 Year = 2011;
 1616 Month = July;
 1617 Day = 31;
 1618 };
 ...
 1629 };

However, the MOF spec was changed between version 3.0.0 and 3.0.1 and I don't think the "instance of" is strictly valid anymore as a "propertyValue" according to the spec:

From DSP0221 3.0.0:

771 complexValue = ( INSTANCE / VALUE ) OF
 772 ( structureName / className / associationName )
 773 [ alias ] propertyValueList

From DSP0221 3.0.1:

772 complexValue = aliasIdentifier /
 773 ( VALUE OF
 774 ( structureName / className / associationName )
 775 propertyValueList ) 

Some possible fixes are:

• Change the complexValue definition to allow "instance of" again. e.g.:

complexValue = aliasIdentifier /
 ( INSTANCE OF
 ( className / associationName )
 propertyValueList ) /
 ( VALUE OF
 ( structureName / className / associationName )
 propertyValueList )

• Update the example in "D.20 JohnDoe.mof" to make it compatible with the changes in the DSP0221 v3.0.1 syntax. e.g.:

instance of GOLF_ClubMember
 {
 ...
 LastPaymentDate = $myGolfDateAliasIdentifier
 ...
 };

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 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...