Getting Unexpected Error on Boot.BootSourceOverrideMode

[dmtf]

Getting Unexpected Error on Boot.BootSourceOverrideMode

[tomasg2012]

Sorry, I read the wrong property in this context and answered you incorrectly, let me look into this property and give you a more accurate response.

[tomasg2012]

After I misunderstood the question, I realized this is a completely different issue of understanding how inheritance works between types. There is a higher version of Boot "v1_1_0" in the Namespace you specified, but because there is no such Property "Boot" in that Namespace that has a BaseType of Boot inside of "v1_1_0", such as "ComputerSystem.v1_1_0.Boot", instead it is only aware of the Property with BaseType "ComputerSystem.v1_0_0.Boot" within that Namespace.

Due to the navigation issue present in the Interop tool, I will be constructing a much more robust tree that should have the ability to alleviate this issue through parental checking.

[jbobzin-insyde]

How are you doing with this one? I am also seeing this on
Chassis.v1_2_0.Links.Storage
I get
ERROR - Links.Storage: Appears to be an extra property (check inheritance or casing?)
which I think is same failure as System.v1_1_0.Boot.BootSourceOverrideMode

[tomasg2012]

Raineri brought up an interesting spec definition that was finalized just this May that Complex objects and Resources should contain an @odata.type, such that it would nullify this issue. (This version is 1.2.0) However, considering backwards compatibility is necessary, the program should still attempt to check for a higher type and inherit from it. The issue is still under work.

[tomasg2012]

This should be fixed in the new pull, which collaborates the highest type available and polls for ComplexType changes (as of now, just Complex).

[jbobzin-insyde]

The false "extra property error" with ComputerSystem.Boot.BootSourceOverrideMode and Chassis.v1_2_0.Links.Storage are still seen after the recent pull.

[tomasg2012]

I apologize, seems that I made the mistake in assuming Schemas, as described in Schema tags in a CSDL file, have a "BaseType". However, it is the EntityType inside the Schemas that have BaseTypes that point to earlier EntityTypes, the current method doesn't actually check types lower than the current one.

It's a simple fix, but I'm not sure which of two approaches is more accurate:

1. List all Schema in the CSDL file and check every version at/below the current Namespace.
2. Check the current Namespace, and use the BaseType of the Entity inside the Namespace to traverse to a lower type.

[mraineri]

Option 2 should be the more appropriate one. With the way we version our namespaces, it's the reliable method.

[tomasg2012]

This should be in the branch 'enhancements-06-12' now. If you would like to give it a try before Thursday, it would be appreciated, sorry for the oversight.

[jbobzin-insyde]

fixed in the latest branch