Arrange encoding information more clearly
Refactor this to put the rules for mapping Encoding Objects to valules with the `encoding` field (which performs the mapping) rather than having most of it in the Encoding Object (which should focus on how to apply a single Encoding Object to a single value). This notably takes the special handling of arrays as repeated values out of the Encoding Object section (and the default `contentType` field value table) and moves it to the Media Type Object. The Encoding Object behavior is now consistent for all types, while the _mapping_ done by the `encoding` field handles the special case. The only change (as opposed to re-organization and re-wording) in this PR is the addition of a default `contentType` of `application/json` for array values, which in the context of the existing behavior is only relevant for array values nested under a top-level array. Past OAS versions were silent on this topic, and presumably it just does not come up much, but it was a gap we should fill. As dicussed in today's TDC call, we have increasing (and modern) use cases for supporting `multipart/mixed` (which we previously claimed to support but never did). This refactor makes possible future support easier by moving the array special case, which is governed by the `multipart/form-data` RFC, out of the Encoding Object (which needs to work with other `multipart` formats) and places it with the `encoding` field (which is web form-format-specific).
H
Henry H. Andrews committed
f2879df2735e2043b967ab2d376f76bc8e64a28a
Parent: e511664