Not parsing right version of schema?

[dmtf]

Not parsing right version of schema?

[tomasg2012]

This error message is a bit vague and doesn't tell the user that this is an Exception error, this error is a result of the XML file used for this resource is missing a reference for Resource.v1_0_0. I'm not sure if the log provides that info but if you can look at the other comment first it might resolve this.

[jbobzin-insyde]

Looking at http://redfish.dmtf.org/schemas/v1/EthernetInterface_v1.xml I see <edmx:Reference Uri="http://redfish.dmtf.org/schemas/v1/Resource_v1.xml"> <edmx:Include Namespace="Resource"/> <edmx:Include Namespace="Resource.v1_0_3"/> <edmx:Include Namespace="Resource.v1_1_2"/> <edmx:Include Namespace="Resource.v1_2_1"/> <edmx:Include Namespace="Resource.v1_3_0"/> </edmx:Reference> So literally you are correct – there is no reference Resource.v1_0_0 But this is DMTF’s file, not my file.

…

---Jeff From: tomasg2012 [mailto:[email protected]] Sent: Friday, May 5, 2017 3:28 PM To: DMTF/Redfish-Service-Validator <[email protected]> Cc: Jeff Bobzin <[email protected]>; Author <[email protected]> Subject: Re: [DMTF/Redfish-Service-Validator] Not parsing right version of schema? (#23) This error message is vague and doesn't tell the user that this is an Exception error, this error is a result of the XML file used for this resource is missing a reference for Resource.v1_0_0. I'm not sure if the log provides that info but if you can look at the other comment first it might resolve this. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub<#23 (comment)>, or mute the thread<https://github.com/notifications/unsubscribe-auth/AHyHgZp2V2lehG4ytuBVpOn67aAu1xM5ks5r23glgaJpZM4NSRgl>.

[tomasg2012]

in the linked XML, the Resource reference is actually

<edmx:Reference Uri="http://redfish.dmtf.org/schemas/v1/Resource_v1.xml">
<edmx:Include Namespace="Resource"/>
<edmx:Include Namespace="Resource.v1_0_0"/>
</edmx:Reference>

But in the metadata from the other post, you are correct, that is shown above. Seems that the problem is that the program is using the $metadata response to determine inheritance when it's supposed to be using the xml of EthernetInterfaces, which is linked in the references. I can't seem to find the area where the key error actually happens.

[jbobzin-insyde]

Should I try to update reference to resource in $metadata?

…

________________________________ From: tomasg2012<mailto:[email protected]> Sent: ‎5/‎5/‎2017 4:13 PM To: DMTF/Redfish-Service-Validator<mailto:[email protected]> Cc: Jeff Bobzin<mailto:[email protected]>; Author<mailto:[email protected]> Subject: Re: [DMTF/Redfish-Service-Validator] Not parsing right version of schema? (#23) in the linked XML, the Resource reference is actually <edmx:Reference Uri="http://redfish.dmtf.org/schemas/v1/Resource_v1.xml"> <edmx:Include Namespace="Resource"/> <edmx:Include Namespace="Resource.v1_0_0"/> </edmx:Reference> But in the metadata from the other post, you are correct, that is shown above. Seems that the problem is that the program is using the $metadata to determine inheritance when it's supposed to be using the xml of EthernetInterfaces. I can't seem to find the area where the key error actually happens. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub<#23 (comment)>, or mute the thread<https://github.com/notifications/unsubscribe-auth/AHyHgZte3-JMB8eKuVUhxbgFsDeTTH8qks5r24L9gaJpZM4NSRgl>.

[tomasg2012]

Personally I wouldn't recommend making changes to please the tool, your $metadata seems appropriate. In fact, the service I currently test against does not have Resource on its $metadata.

I'm a little under the weather right now, so I apologize if the code comes slow.

[tomasg2012]

A new branch has been made, test it if you please.

[jbobzin-insyde]

Tomas, Discovered the Validator program went off the rails due to an odata typo in the page from the system was parsing. Inspecting closely I found more than 1 typo actually. Looks to be cut and paste error by programmer. Have requested patch from our developers. Will resume testing when that comes back. Couple days. So the Program is finding problems. Which is good. But not always easy to identify the typo based on the program output. Wish list would include the program being augmented to not trust the odata but rather split out clearer error when an odata field does not work. For example, if odata.context or odata.type does not resolve with the $metadata provided then test is done. Probably better to declare fatal and just quit at the point bad odata field is found. Currently it seems to try to continue and go off into the weeds. So tester needs to work backwards in the log. Not sure how practical you will find these suggestions. But I am happy and making progress in any case. Once I get a clean run I will share the mockup with you. Not sensible to share mockup right now with the typos. ---jeff

[tomasg2012]

Thank a ton for the feedback, it helps plenty. I've been talking with others about how the output and responses to certain types of errors should be, it's improved quite a bit and I'll try to get something more easily digestible by this Thursday.

Much like the References XML problem from the last iteration of the program before the pull request, it's an honest mistake to expect no mechanical errors with some of these inputs. Would you be able to respond with the odata typos in question?

[jbobzin-insyde]

Sample 1. odata.context had badly formed text string, could not resolve to a xml defining the type 2. odata.context and .type did not agree due to editing error (choosing wrong string) Of course, some expert many know of a situation where odata.type and odata.context do not need to agree in base type name. Is this a rule or a custom? But certainly non-agreement is not something I have seen in a mockup. But my idea - for these fundamental odata lapses I would suggest program immediately print error and exit when encountered.

[mraineri]

I think both @odata.type and @odata.context need to have some level of agreement, otherwise I don't see how a client could sanely decode the payload.

But I agree; it would be better for the tool to detect the condition, print it, and exit with an error gracefully rather than just throw an exception.

[jbobzin-insyde]

Problem was in test system