Possible missing ";" in MOF Spec 3.0.1 example "D.5 GOLF_Professional"

[mikeclayton]

In section "D.5 GOLF_Professional" of the MOF Spec 3.0.1 there's an example class with a number of propertyDeclarations and methodDeclaration:

class GOLF_Professional : GOLF_ClubMember {
...
    GOLF_ResultCodeEnum GetNumberOfProfessionals (
        [Out] Integer NoOfPros,
        [In] GOLF_Club Club,
        [In] ProfessionalStatusEnum Status = Professional
    )
...
};

The GetNumberOfProfessionals methodDeclaraction is not terminated by a trailing ";" which means the file fails to parse with the following exception:

Message: Kingsland.MofParser.Parsing.UnexpectedTokenException : Unexpected token found at Position 1181, Line Number 31, Column Number 1.
Token Type: 'BlockCloseToken'
Token Text: '}'

To do:

• Fix the sample by adding a trailing ";"
• Report the issue using the DMTF feedback form

[mikeclayton]

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

---

Hi,

This is probably a simple typo, but I think I've found a small typo in one of the example texts in the Managed Object Format 3.0.1 specification here:

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

In section "D.5 GOLF_Professional" there's the following example class declaration:

1267 class GOLF_Professional : GOLF_ClubMember {
...
1283 GOLF_ResultCodeEnum GetNumberOfProfessionals (
1284 [Out] Integer NoOfPros,
1285 [In] GOLF_Club Club,
1286 [In] ProfessionalStatusEnum Status = Professional
1287 )
1288 };

I think the GetNumberOfProfessionals method declaration needs a semicolon at the end, so that line 1287 becomes:

1287 );

Otherwise, it doesn't satisfy the definition of methodDeclaration here:

654 methodDeclaration = [ qualifierList ]
655 ( ( returnDataType [ array ] ) / VOID ) methodName
656 "(" [ parameterList ] ")" ";"

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