Draft release notes for 3.2.0 and 3.1.2

[lornajane]

Opening this as a pull request purely as a good way to collaborate - DO NOT MERGE.

The content will be added to the github release.

[miqui]

@lornajane So far looks good to me.

[jeremyfiel]

should add more detailed info on new keywords in MediaType object.

[lornajane]

@jeremyfiel can you say something about what's missing? (I obviously don't know or it wouldn't be missing ...) I did just update with some of the changes from the last couple of weeks, but I don't think there is anything here that would match what you're asking for.

[handrews]

Suggested change

	- XML namespaces can be IRIs (rather than URIs)
	- Explanation and example on how to handle `null` in XML
	- New `nodeType` field allows maping schemas to all common XML node types (elements, attributes, text, or cdata) or to nothing
	- `attribute: true` deprecated in favor of `nodeType: attribute`
	- `wrapped: true` deprecated in favor of `nodeType: element` (as `nodeType` defaults to `none` for arrays to preserve compatibility)
	- The `xml` keyword can be used in any Schema Object
	- XML namespaces can be IRIs (rather than URIs)
	- Explanation and example on how to handle `null` in XML

[handrews]

Suggested change

	### Parameters
	- additional parameter location `querystring`, to allow parsing the entire query string as a single field similar to the way a request body is handled, using the `content` field. Useful for complex or unconventional query data. Mutually exclusive with the `query` field.
	- parameters can therefore be `in` the `querystring` as an alternative to the existing `header`, `cookie`, `query` and `path` values.
	- `allowReserved` field is now permitted on parameters with any value of `in` (however this many not be a Good Idea (TM) in some scenarios)
	### Parameters and Headers
	- additional parameter location `querystring`, to allow parsing the entire query string as a single field similar to the way a request body is handled, using the `content` field. Useful for complex or unconventional query data. Mutually exclusive with the `query` field.
	- parameters can therefore be `in` the `querystring` as an alternative to the existing `header`, `cookie`, `query` and `path` values.
	- `allowReserved` field is now permitted on parameters and headers with any value of `in` (however this many not be a Good Idea (TM) in some scenarios)

[handrews]

This is now covered under "Parameters and Headers"

[handrews]

I don't think we changed anything here? PR #4648 allows additional use of example/examples for both Parameter and Header fields, but that has not merged yet?

[handrews]

Suggested change

	### Discriminator
	- no change from previous versions: use `discriminator` to hint which entry in `anyOf` or `oneOf` is expected.
	- no change from previous versions: use `mapping` to link the discriminator property value to the Schema name if they aren't an exact match.
	- the discriminator `propertyName` can now be an optional field.
	- additional `defaultMapping` field to indicate which schema to use if the `propertyName` is not set, or if the value is unrecognized.
	### Code Generatoin
	- the discriminator `propertyName` can now be an optional field.
	- additional `defaultMapping` field to indicate which schema to use if the `propertyName` is not set, or if the value is unrecognized.
	- no change from previous versions: use `discriminator` to hint which entry in `anyOf` or `oneOf` is expected.
	- no change from previous versions: use `mapping` to link the discriminator property value to the Schema name if they aren't an exact match.
	- Implementations now SHOULD (rather than MAY) support templates/generics using `$dynamicRef`

[jeremyfiel]

Code Generation

[handrews]

Same comment as under 3.2