v3.1 specification: minor clarifications, markup improvements #4998
Conversation
- Literal style names are now rendered in sans-serif as code - "primitive" is not rendered as code, as it refers to one of string, number, boolean or null, not a literal type name.
| ##### Style Values | ||
|
|
||
| In order to support common ways of serializing simple parameters, a set of `style` values are defined. | ||
| In order to support common ways of serializing simple parameters, a set of `style` values are defined. Combinations not represented in this table are not permitted. |
There was a problem hiding this comment.
That adds a MUST NOT requirement, which we cannot do in a patch release.
There was a problem hiding this comment.
This requirement already existed; it is not adding a new one. It was just not mentioned here.
There was a problem hiding this comment.
It's the table itself here that sets out the permitted combinations of styles and in. But this is the way it's been since at least 3.0, and the schemas also set out these restrictions (see the "styles-for-path", "styles-for-header" etc definitions) -- so I believe the very strong intent is that no other combinations are permitted.
There was a problem hiding this comment.
The 3.2 spec contains this language and the same table of combinations of styles and in, and we did not change any aspect of this spec (other than adding in: querystring and style: cookie) in 3.2; the schemas are also identical between 3.1 and 3.2. If the restriction had been new in 3.2, it would have been a breaking change, which we do not do in minor releases.
So this is just a clarification, not a change.
This is a port of the relevant bits in #4959.
Literal style names are now rendered in sans-serif as code
"primitive" is not rendered as code, as it refers to one of string, number, boolean or null, not a literal type name.
be explicit that the style table shows ALL valid combinations
no schema changes are needed for this pull request