A "warnings" member MUST encapsulate the warnings that will be returned to the client.
In some rare cases when warnings happens to be a member is the response schema, this may break the client because of the ambiguity.
Suggestion: If the member name is allowed to be flexible with warnings as the default, this problem can be overcome. Further we can add an additional optional token in the Content-Warning header to identify the name of the member which holds the embedded warnings.
Section 5 of the draft mandates the following:
In some rare cases when warnings happens to be a member is the response schema, this may break the client because of the ambiguity.
Suggestion: If the member name is allowed to be flexible with warnings as the default, this problem can be overcome. Further we can add an additional optional token in the Content-Warning header to identify the name of the member which holds the embedded warnings.
For ex.
Content-Warning: "embedded-warning"; 1590190500; "_warnings"
For the cases where the warning is embedded into a response xml this could be an xpath.