v3.2: Decide on names of new Example Object fields

[handrews]

PR #4647 adds four new fields to the Example Object. There seems to be consensus that we should add the fields once that PR is out of draft, but there is less consensus on the names.

In this issue, "JSON/YAML" refers to JSON (as specified by the RFC) and the subset of YAML that we allow for OAD authoring. This subset is intended to be essentially equivalent to JSON, as all OAD keys and values MUST be possible to write in JSON.

The names in the PR are:

• dataValue: An inline example value of the data structure that is validated by a Schema Object, possibly trivially if the data is raw binary as that is outside of JSON Schema's standard data model
• externalDataValue: Like dataValue but for values not possible to inline in JSON/YAML, such as a raw binary image or video
• serializedValue: An inline example of the fully serialized value, which MUST be a string
• externalSerializedValue: Like serializedValue but for values not possible to inline as a JSON/YAML string.

@mikekistler has questioned "data" and brought up that JSON Schema uses "instance." My feeling is that "instance" is too jargon-y, and the data is not necessarily a proper JSON Schema instance when binary data is involved, but I could be convinced to go with it if I'm in the minority here.

[handrews]

BTW I do not care what the names are. Just lmk when there's consensus and I'm happy to write a PR to update the text with the final names. I have just separated this out (and made it a 3.2 release blocker) so that PRs #4647 and #4648 do not get held up on naming debates.

[hudlow]

I can't usefully contribute to a naming discussion separate from a semantics discussion unless the semantics are clear to me (and finalized), which they are not. I have commented with my objections, here: #4671 (comment).

[mikekistler]

Regarding "DataValue", I would prefer a more descriptive name since "data" is very generic. My first thought was "JsonValue", since we want this to match the JSON Schema.

[ralfhandl]

I'm fine with either dataValue or jsonValue.

[karenetheridge]

jsonValue could suggest that the value is json-encoded, which it isn't.