docs(repo): update documentation to reflect OpenAPI 3.2 support

Author: mkistler

README.md

@@ -2,7 +2,7 @@
 [![CircleCI](https://img.shields.io/circleci/build/github/stoplightio/spectral/develop)](https://circleci.com/gh/stoplightio/spectral) [![npm Downloads](https://img.shields.io/npm/dw/@stoplight/spectral-core?color=blue)](https://www.npmjs.com/package/@stoplight/spectral-core) [![Stoplight Forest](https://img.shields.io/ecologi/trees/stoplightinc)][stoplight_forest]
 
 - **Custom Rulesets**: Create custom rules to lint JSON or YAML objects
-- **Ready-to-use Rulesets**: Validate and lint **OpenAPI v2 & v3.x**, **AsyncAPI**, and **Arazzo v1** Documents
+- **Ready-to-use Rulesets**: Validate and lint **OpenAPI v2, v3.0, v3.1 & v3.2**, **AsyncAPI**, and **Arazzo v1** Documents
 - **API Style Guides**: Automated [API Style Guides](https://stoplight.io/api-style-guides-guidelines-and-best-practices?utm_source=github.com&utm_medium=referral&utm_campaign=github_repo_spectral) using rulesets improve consistency across all your APIs
 - **Ready-to-use Functions**: Built-in set of functions to help [create custom rules](https://meta.stoplight.io/docs/spectral/e5b9616d6d50c-custom-rulesets#adding-rules). Functions include pattern checks, parameter checks, alphabetical ordering, a specified number of characters, provided keys are present in an object, etc.
 - **Custom Functions**: Create custom functions for advanced use cases

docs/getting-started/4-openapi.md

@@ -2,6 +2,6 @@
 
 Spectral has a built-in [OpenAPI Specification](https://openapis.org/specification) ruleset that you can use to validate your OpenAPI files.
 
-Add `extends: "spectral:oas"` ("oas" being shorthand for OpenAPI Specification) to your ruleset file to apply rules for OpenAPI v2 and v3.x, depending on the appropriate OpenAPI version being used (this is automatically detected through [formats](../getting-started/3-rulesets.md#formats)).
+Add `extends: "spectral:oas"` ("oas" being shorthand for OpenAPI Specification) to your ruleset file to apply rules for OpenAPI v2, v3.0, v3.1, and v3.2, depending on the appropriate OpenAPI version being used (this is automatically detected through [formats](../getting-started/3-rulesets.md#formats)).
 
 You can see a full list of the rules in this ruleset in [OpenAPI Rules](../reference/openapi-rules.md).

docs/guides/4-custom-rulesets.md

@@ -37,6 +37,7 @@ Formats are an optional way to specify which API description formats a rule, or
 - `oas3` (OpenAPI v3.x)
 - `oas3_0` (OpenAPI v3.0.x)
 - `oas3_1` (OpenAPI v3.1.x)
+- `oas3_2` (OpenAPI v3.2.x)
 - `json-schema` (`$schema` says this is some JSON Schema draft)
 - `json-schema-loose` (looks like JSON Schema, but no `$schema` found)
 - `json-schema-draft4` (`$schema` says this is JSON Schema Draft 04)

docs/reference/openapi-rules.md

@@ -6,7 +6,7 @@ In your ruleset file you can add `extends: "spectral:oas"` and you'll get all of
 
 ## OpenAPI v2 & v3
 
-These rules apply to both OpenAPI v2.0, v3.0, and most likely v3.1, although there are some differences.
+These rules apply to OpenAPI v2.0, v3.0, v3.1, and v3.2, although there are some differences.
 
 ### contact-properties
 
@@ -635,7 +635,7 @@ paths:
 
 ## OpenAPI v3-only
 
-These rules will only be applied to OpenAPI v3.0 documents.
+These rules will only be applied to OpenAPI v3.0, v3.1, and v3.2 documents.
 
 ### oas3-api-servers
 
@@ -696,7 +696,7 @@ Parameter objects should have a `description`.
 ### oas3-schema
 
 Validate structure of OpenAPI v3 specification.
-If OpenAPI 3.1.0 is used, `jsonSchemaDialect` is not respected and the draft 2020-12 is applied.
+If OpenAPI 3.1 or 3.2 is used, `jsonSchemaDialect` is not respected and the draft 2020-12 is applied.
 If you define your own `jsonSchemaDialect`, you'll most likely want to disable this rule.
 
 **Recommended:** Yes
@@ -880,7 +880,7 @@ schemas:
 
 ### oas3-server-variables
 
-This rule ensures that server variables defined in OpenAPI Specification 3 (OAS3) and 3.1 are valid, not unused, and result in a valid URL. Properly defining and using server variables is crucial for the accurate representation of API endpoints and preventing potential misconfigurations or security issues.
+This rule ensures that server variables defined in OpenAPI Specification 3 (OAS3), 3.1, and 3.2 are valid, not unused, and result in a valid URL. Properly defining and using server variables is crucial for the accurate representation of API endpoints and preventing potential misconfigurations or security issues.
 
 **Recommended**: Yes
 
@@ -975,7 +975,7 @@ paths:
 
 ### oas3_1-servers-in-webhook
 
-Servers should not be defined in a webhook.
+Servers should not be defined in a webhook. Applies to OpenAPI v3.1 and v3.2.
 
 **Recommended:** Yes
 
@@ -1004,7 +1004,7 @@ webhooks:
 
 ### oas3_1-callbacks-in-webhook
 
-Callbacks should not be defined in a webhook.
+Callbacks should not be defined in a webhook. Applies to OpenAPI v3.1 and v3.2.
 
 **Recommended:** Yes
 
@@ -1016,3 +1016,39 @@ webhooks:
     post:
       callbacks: ...
 ```
+
+## OpenAPI v3.2-only
+
+These rules will only be applied to OpenAPI v3.2 documents.
+
+### oas3_2-no-deprecated-xml-attribute
+
+The `xml.attribute` field is deprecated in OpenAPI v3.2. Use `xml.nodeType: attribute` instead.
+
+**Recommended:** Yes
+
+**Bad Example**
+
+```yaml
+components:
+  schemas:
+    Pet:
+      properties:
+        name:
+          type: string
+          xml:
+            attribute: true
+```
+
+**Good Example**
+
+```yaml
+components:
+  schemas:
+    Pet:
+      properties:
+        name:
+          type: string
+          xml:
+            nodeType: attribute
+```