@mikekistler noticed the text that (since at least 3.0) has said that examples outside of the Schema Object "override" examples inside of it, and questioned why it should be there.
I think it has to do with the original purpose of the various fields. In this table, I use the PR #4647 field names to describe the intended purpose and actual implementation:
| Object(s) | Field | Intended Purpose | Actual Implementation |
|---|
| Schema | example | dataValue | dataValue |
| Schema | examples | dataValue | dataValue |
| Parameter, Header, Media Type | example | serializedValue (but inline if representable in JSON | often dataValue but not always? |
| Example | value | serializedValue (but inline if representable in JSON | often dataValue but not always? |
| Example | externalValue | externalSerializedValue (but inline if representable in JSON | often dataValue but not always? |
So I think "override" just meant "the serialized version is what you actually send/receive", not "the Schema example is wrong and the other example is right."
So maybe there is a clarification of wording there?
@mikekistler noticed the text that (since at least 3.0) has said that examples outside of the Schema Object "override" examples inside of it, and questioned why it should be there.
I think it has to do with the original purpose of the various fields. In this table, I use the PR #4647 field names to describe the intended purpose and actual implementation:
exampledataValuedataValueexamplesdataValuedataValueexampleserializedValue(but inline if representable in JSONdataValuebut not always?valueserializedValue(but inline if representable in JSONdataValuebut not always?externalValueexternalSerializedValue(but inline if representable in JSONdataValuebut not always?So I think "override" just meant "the serialized version is what you actually send/receive", not "the Schema example is wrong and the other example is right."
So maybe there is a clarification of wording there?