diff --git a/.github/workflows/github-pages.yml b/.github/workflows/github-pages.yml new file mode 100644 index 00000000..130e153b --- /dev/null +++ b/.github/workflows/github-pages.yml @@ -0,0 +1,51 @@ +# Sample workflow for building and deploying a Jekyll site to GitHub Pages +name: deploy github pages + +on: + # Runs on pushes targeting the default branch + push: + branches: ["main"] + + # Allows you to run this workflow manually from the Actions tab + workflow_dispatch: + +# Sets permissions of the GITHUB_TOKEN to allow deployment to GitHub Pages +permissions: + contents: read + pages: write + id-token: write + +# Allow only one concurrent deployment, skipping runs queued between the run in-progress and latest queued. +# However, do NOT cancel in-progress runs as we want to allow these production deployments to complete. +concurrency: + group: "pages" + cancel-in-progress: true + +jobs: + # Build job + build: + runs-on: ubuntu-latest + steps: + - name: Checkout + uses: actions/checkout@v4 + - name: Setup Pages + uses: actions/configure-pages@v5 + - name: Build with Jekyll + uses: actions/jekyll-build-pages@v1 + with: + source: ./ + destination: ./_site + - name: Upload artifact + uses: actions/upload-pages-artifact@v3 + + # Deployment job + deploy: + environment: + name: github-pages + url: ${{ steps.deployment.outputs.page_url }} + runs-on: ubuntu-latest + needs: build + steps: + - name: Deploy to GitHub Pages + id: deployment + uses: actions/deploy-pages@v5 diff --git a/README.md b/README.md index e5ac7787..cce0f9b0 100644 --- a/README.md +++ b/README.md @@ -986,7 +986,7 @@ Here is an example of JSON output: "entries": [] } }, - "hasResults": true + "hasResults": true, "impactScore": { "categorizedSummary": { "usability": 94, diff --git a/_config.yml b/_config.yml new file mode 100644 index 00000000..206705ca --- /dev/null +++ b/_config.yml @@ -0,0 +1,16 @@ +title: IBM OpenAPI Validator +description: A highly configurable linter/validator for OpenAPI documents. +theme: minima + +exclude: + - README.md + - CHANGELOG.md + - CONTRIBUTING.md + - Migration-Guide.md + - docs/automated-quality-screening.md + - docs/openapi-ruleset-utilities.md + - packages/ + - node_modules/ + - scripts/ + - coverage/ + - test-local/ diff --git a/_sass/custom.scss b/_sass/custom.scss new file mode 100644 index 00000000..1a0e2b33 --- /dev/null +++ b/_sass/custom.scss @@ -0,0 +1,27 @@ +// Fix table layout so they never cause horizontal page scroll. +// Tables are constrained to the wrapper width; pre blocks inside +// cells scroll only within the cell (vertically wrapping the content). + +.post-content { + table { + table-layout: fixed; + width: 100%; + word-wrap: break-word; + overflow-wrap: break-word; + + td, th { + word-wrap: break-word; + overflow-wrap: break-word; + } + + // pre / code blocks inside table cells: scroll horizontally within + // the cell only, never overflow the page. + td pre, th pre { + overflow-x: auto; + max-width: 100%; + white-space: pre; + word-wrap: normal; + overflow-wrap: normal; + } + } +} diff --git a/assets/main.scss b/assets/main.scss new file mode 100644 index 00000000..456bc665 --- /dev/null +++ b/assets/main.scss @@ -0,0 +1,6 @@ +--- +# Only the main Sass file needs front matter (the dashes are enough) +--- + +@import "minima"; +@import "custom"; diff --git a/docs/ibm-cloud-rules.md b/docs/ibm-cloud-rules.md index 049baf85..578d5cf5 100644 --- a/docs/ibm-cloud-rules.md +++ b/docs/ibm-cloud-rules.md @@ -404,7 +404,7 @@ should probably be required instead of optional. ibm-no-superfluous-allof warn -Warns about schemas that contain only a single-element allOf, which are unnecessary./td> +Warns about schemas that contain only a single-element allOf, which are unnecessary. oas3 @@ -517,7 +517,6 @@ or application/merge-patch+json. oas3 - ibm-property-casing-convention error Schema property names should follow a specific case convention. @@ -542,7 +541,6 @@ or application/merge-patch+json. oas3 - ibm-ref-pattern warn Ensures that $ref values follow the correct patterns. @@ -587,6 +585,7 @@ has non-form content. This rule is disabled by default. Operations that create or update a resource should return the same schema as the "GET" request for the resource. oas3 + ibm-response-status-codes warn Performs multiple checks on the status codes used in operation responses. @@ -594,7 +593,7 @@ has non-form content. This rule is disabled by default. ibm-schema-casing-convention -warm +warn Schema names should follow a specific case convention. oas3 @@ -779,8 +778,7 @@ npm install @ibm-cloud/openapi-ruleset If you would simply like to modify a rule's severity or disable a rule altogether, follow the instructions in this section. -> [!CAUTION] -> Disabling certain rules may lead to false negatives for problems identified by other rules. +> **Caution:** Disabling certain rules may lead to false negatives for problems identified by other rules. > > For example, if you disable the `ibm-schema-type-format` rule, other rules which detect problems > in schemas with specific combinations of `type` and `format` may fail to identify which schemas @@ -900,6 +898,7 @@ This section provides reference documentation about the IBM Cloud Validation Rul in the `@ibm-cloud/openapi-ruleset` package. ### ibm-accept-and-return-models + @@ -920,7 +919,7 @@ The - +
Rule id:oas3
Non-compliant example:Non-compliant example: 
 requestBody:
@@ -959,6 +958,7 @@ requestBody:
### ibm-anchored-patterns + @@ -981,7 +981,7 @@ since an un-anchored regular expression might match on only part of the string i - +
Rule id:oas3
Non-compliant example:Non-compliant example: 
 components:
@@ -1013,6 +1013,7 @@ components:
### ibm-api-symmetry + @@ -1037,7 +1038,7 @@ Note: the rule will report additional details about each violation of the graph - +
Rule id:oas3
Non-compliant example:Non-compliant example: 
 components:
@@ -1120,6 +1121,7 @@ paths:
 
 
 ### ibm-array-attributes
+
 
@@ -1139,7 +1141,7 @@ paths:
 
-
+

 

 Rule id:oas3
 

 
Non-compliant example:Non-compliant example:
 
 
 components:
@@ -1173,6 +1175,7 @@ components:
 
 
 ### ibm-avoid-inline-schemas
+
 
@@ -1185,8 +1188,10 @@ the SDK generator typically needs to refactor these inline schemas in order to c
 computed by the SDK generator are unlikely to be optimal from a readability standpoint.
 
Specifically, this rule warns about the use of inline object schemas within request bodies, responses,
 and nested schemas (e.g. a schema property, an array items schema, an additionalProperties schema, etc.).
+
More information about this can be found in the
 API Handbook.
+

@@ -1198,7 +1203,7 @@ and nested schemas (e.g. a schema property, an array items schema,
 
-
+

 

 Rule id:
 
 
 

 
oas3
 

 
Non-compliant example:Non-compliant example:
 
 
 components:
@@ -1299,6 +1304,7 @@ paths:
 
 
 ### ibm-avoid-multiple-types
+
 
@@ -1312,6 +1318,7 @@ ambiguity in an API definition.  Therefore, multiple types should be avoided.
 One exception to this is that the special type "null" is simply ignored by the rule when counting 
 the number of elements in the schema's type field.  So, the type value ['string', 'integer']
 would cause an error, but the type value ['string', 'null'] would not.
+

@@ -1323,7 +1330,7 @@ would cause an error, but the type value ['string', 'null'] would n
 
-
+

 

 Rule id:
 
 

 
oas3_1
 

 
Non-compliant example:Non-compliant example:
 
 
 components:
@@ -1366,6 +1373,7 @@ components:
 
 
 ### ibm-avoid-property-name-collision
+
 
@@ -1385,7 +1393,7 @@ components:
 
-
+

 

 Rule id:oas3
 

 
Non-compliant example:Non-compliant example:
 
 
 components:
@@ -1422,6 +1430,7 @@ components:
 
 
 ### ibm-avoid-repeating-path-parameters
+
 
@@ -1433,6 +1442,7 @@ components:
 defining it separately within each of the operations that exist for that path.
 
This rule checks for situations in which a path parameter is defined identically within multiple operations under a given path,
 and returns a warning to alert the user that the path parameter should be defined on the path object instead.
+

@@ -1444,7 +1454,7 @@ and returns a warning to alert the user that the path parameter should be define
 
-
+

 

 Rule id:
 
 

 
oas3
 

 
Non-compliant example:Non-compliant example:
 
 
 paths:
@@ -1491,6 +1501,7 @@ paths:
 
 
 ### ibm-binary-schemas
+
 
@@ -1516,7 +1527,7 @@ Specifically, the rule will check to make sure a binary schema is NOT used in th
 
-
+

 

 Rule id:oas3
 

 
Non-compliant example:Non-compliant example:
 
 
 paths:
@@ -1557,6 +1568,7 @@ paths:
 
 
 ### ibm-collection-array-property
+
 
@@ -1573,12 +1585,16 @@ with an array property named "things" (which is presumably defined as an array o
 "list"-type operation (with or without support for pagination) to make sure that the operation's
 response schema defines an array property whose name matches the last path segment
 within the operation's path string, which should also match the plural form of the resource type.
+
For the purposes of this rule, an operation is considered to be a "list"-type operation
 if it is a "get" request and one of the following are also true:
+
    
 
  1. the operation's operationId starts with "list" (e.g. "list_things")
+
    2. 
 
  2. the operation's path string does not end with a path parameter reference, but there is a
 companion path string that does end with a path parameter reference (e.g. "/v1/things" vs "/v1/things/{thing_id}").
+
    3. 
 

@@ -1591,7 +1607,7 @@ companion path string that does end with a path parameter reference (e.g. "/v1/t
 
-
+

 

 Rule id:
 
 
 
 
oas3
 

 
Non-compliant example:Non-compliant example:
 
 
 paths:
@@ -1638,6 +1654,7 @@ paths:
 
 
 ### ibm-content-contains-schema
+
 
@@ -1657,7 +1674,7 @@ paths:
 
-
+

 

 Rule id:oas3
 

 
Non-compliant example:Non-compliant example:
 
 
 responses:
@@ -1687,6 +1704,7 @@ responses:
 
 
 ### ibm-content-type-is-specific
+
 
@@ -1697,6 +1715,7 @@ responses:
 
@@ -1708,7 +1727,7 @@ unless the API actually supports all content types.
 
-
+

 

 Rule id:The use of */* as a mimetype within a content field should be avoided
 unless the API actually supports all content types.
 
If the API in fact supports all content types, this warning should be ignored.
+

 		
 

 
oas3
 

 
Non-compliant example:Non-compliant example:
 
 
 requestBody:
@@ -1735,6 +1754,7 @@ requestBody:
 
 
 ### ibm-define-required-properties
+
 
@@ -1761,7 +1781,7 @@ The property could be defined in any of the following ways:
 
-
+

 

 Rule id:oas3
 

 
Non-compliant example:Non-compliant example:
 
 
 components:
@@ -1800,6 +1820,7 @@ components:
 
 
 ### ibm-discriminator-property
+
 
@@ -1827,7 +1848,7 @@ This includes the following validations:
 
-
+

 

 Rule id:oas3
 

 
Non-compliant example:Non-compliant example:
 
 
 components:
@@ -1870,6 +1891,7 @@ components:
 
 
 ### ibm-dont-require-merge-patch-properties
+
 
@@ -1881,6 +1903,7 @@ components:
 with application/merge-patch+json requestBody content should not
 define any required properties or specify a non-zero value for the minProperties field.
 
This rule verifies that "merge-patch" operations adhere to this requirement.
+

@@ -1892,7 +1915,7 @@ define any required properties or specify a non-zero value for the minProp
 
-
+

 

 Rule id:
 
 

 
oas3
 

 
Non-compliant example:Non-compliant example:
 
 
 paths:
@@ -1950,6 +1973,7 @@ components:
 
 
 ### ibm-enum-casing-convention
+
 
@@ -1976,6 +2000,7 @@ that is the appropriate configuration to be used by Spectral's casing()1]
 to enforce the desired case convention for enum values.
 
The default configuration object provided in the rule definition is:
+

 
 {
   type: 'snake'
@@ -1986,6 +2011,7 @@ to enforce the desired case convention for enum values.
 custom ruleset and modify the configuration such that the value of the type field 
 specifies the desired case convention.
 For example, to enforce camel case for enum values, the configuration object would look like this:
+

 
 {
   type: 'camel'
@@ -1994,7 +2020,7 @@ For example, to enforce camel case for enum values, the configuration object wou
 
 

-
+

 

 Rule id:

 
Non-compliant example:Non-compliant example:
 
 
 components:
@@ -2025,6 +2051,7 @@ components:
 
 
 ### ibm-error-content-type-is-json
+
 
@@ -2046,7 +2073,7 @@ This rule should be ignored when the API actually returns an error response that
 
-
+

 

 Rule id:oas3
 

 
Non-compliant example:Non-compliant example:
 
 
 responses:
@@ -2073,6 +2100,7 @@ responses:
 
 
 ### ibm-error-response-schemas
+
 
@@ -2082,6 +2110,7 @@ responses:
 
-
+

 

 Rule id:Description:
 This rule implements the guidance related to error response schemas found in the API Handbook.
 
Specifically, the following checks are performed against each schema associated with an error response:
+

 
    
 
  • The error response schema should form a valid
 error container model as
@@ -2104,7 +2133,7 @@ as described in the API Handbook.
    • 
 
oas3
 

 
Non-compliant example:Non-compliant example:
 
 
 paths:
@@ -2224,6 +2253,7 @@ components:
 
 
 ### ibm-etag-header
+
 
@@ -2240,6 +2270,7 @@ to provide a value for the If-Match or If-None-Match h
 (sometimes referred to as an "etag value"), then the API should provide a way for the user to obtain the etag value.
 And the standard way for a service to provide an etag value to the user is by returning it as the ETag response header
 within the GET operation's response.
+

@@ -2251,7 +2282,7 @@ within the GET operation's response.
 
-
+

 

 Rule id:
 
 

 
oas3
 

 
Non-compliant example:Non-compliant example:
 
 
 paths:
@@ -2333,6 +2364,7 @@ paths:
 
 
 ### ibm-integer-attributes
+
 
@@ -2354,7 +2386,7 @@ is specified as int32 or int64.
 
-
+

 

 Rule id:oas3
 

 
Non-compliant example:Non-compliant example:
 
 
 components:
@@ -2391,6 +2423,7 @@ components:
 
 
 ### ibm-major-version-in-path
+
 
@@ -2412,7 +2445,7 @@ The API major version can appear in either the server URL or in each path entry.
 
-
+

 

 Rule id:oas3
 

 
Non-compliant example:Non-compliant example:
 
 
 openapi: 3.0.1
@@ -2443,6 +2476,7 @@ paths:
 
 
 ### ibm-no-accept-header
+
 
@@ -2508,6 +2542,7 @@ paths:
 
 
 ### ibm-no-ambiguous-paths
+
 

 

 Rule id:

@@ -2525,12 +2560,16 @@ In general, two paths are ambiguous if the following are true:
 
  • one or the other of the path segments is parameterized (e.g. 'foo' vs '{foo_id}')
  • both of the path segments are parameterized (e.g. '{foo_id}' vs '{id}')
    • 
+
 Here are examples of paths that are ambiguous despite being unique:
 
      
 
    • /v1/things/{thing_id}, /v1/things/{id}
+
      • 
 
    • /v1/things/{thing_id}, /v1/things/other_things
+
      • 
 
    • /{version}/things, /v1/{things}
+
      • 
 
    
 Each of the pairs of path strings above would be considered ambiguous.
 
@@ -2575,6 +2614,7 @@ paths:
 
 
 ### ibm-no-array-of-arrays
+
 
    
 
    
 Rule id:
 
 
 
    
@@ -2593,7 +2633,7 @@ paths:
 
-
+
    
 
    
 Rule id:oas3
 
    
 
    Non-compliant example:Non-compliant example:
 
 
     requestBody:
@@ -2626,6 +2666,7 @@ requestBody:
 
 
 ### ibm-no-array-responses
+
 
@@ -2637,6 +2678,7 @@ requestBody:
 The recommendation is to instead use an object with a property that contains the array.
 This will allow you to expand the definition of the response body (e.g. add new properties) in a compatible way
 in the future if needed.
+
@@ -2647,7 +2689,7 @@ in the future if needed.
 
-
+
    
 
    
 Rule id:
 
    
 
    
 Severity:oas3
 
    
 
    Non-compliant example:Non-compliant example:
 
 
     paths:
@@ -2689,13 +2731,13 @@ paths:
 sample response body:
 {"things": [ {"name": "thing-1"}, {"name": "thing-2"} ]}
 
    
-
     		
 
    
 
    
 
 
 ### ibm-no-authorization-header
+
 
@@ -2710,9 +2752,11 @@ The security object can be defined at an operation level (which wou
 that operation) or at a global level within the API definition (which would apply to all operations).
 
    Within generated SDKs, the Authorization header will be managed automatically by the
 built-in authenticator support.
+
    Non-SDK users (those using curl, for example) can infer
 the use of the Authorization header from the security object in the API definition
 together with other documentation provided for the service.
+
    
@@ -2724,7 +2768,7 @@ together with other documentation provided for the service.
 
-
+
    
 
    
 Rule id:
 
 
 
    
 
    oas3
 
    
 
    Non-compliant example:Non-compliant example:
 
 
     paths:
@@ -2780,6 +2824,7 @@ paths:
 
 
 ### ibm-no-body-for-delete
+
 
@@ -2789,6 +2834,7 @@ paths:
 
@@ -2800,7 +2846,7 @@ paths:
 
-
+
    
 
    
 Rule id:Description:
 This rule checks each DELETE operation and will return a warning if the operation contains a requestBody.
 
    This rule has been deprecated and is now disabled in the IBM Cloud Validation Ruleset. Please use the ibm-no-operation-requestbody rule instead.
+
    
     		
 
    
 
    oas3
 
    
 
    Non-compliant example:Non-compliant example:
 
 
     paths:
@@ -2841,6 +2887,7 @@ paths:
 
 
 ### ibm-no-circular-refs
+
 
@@ -2867,7 +2914,7 @@ Any reference to either "Foo" or "Bar" will be a circular reference.
 
-
+
    
 
    
 Rule id:oas3
 
    
 
    Non-compliant example:Non-compliant example:
 
 
     components:
@@ -2909,6 +2956,7 @@ components:
 
 
 ### ibm-no-consecutive-path-parameter-segments
+
 
@@ -2930,7 +2978,7 @@ For example, the path /v1/foos/{foo_id}/{bar_id} is invalid and sho
 
-
+
    
 
    
 Rule id:oas3
 
    
 
    Non-compliant example:Non-compliant example:
 
 
     paths:
@@ -2963,6 +3011,7 @@ paths:
 
 
 ### ibm-no-content-type-header
+
 
@@ -2983,7 +3032,7 @@ Note that the Content-Type header parameter is managed automaticall
 
-
+
    
 
    
 Rule id:oas3
 
    
 
    Non-compliant example:Non-compliant example:
 
 
     paths:
@@ -3038,6 +3087,7 @@ paths:
 
 
 ### ibm-no-crn-path-parameters
+
 
@@ -3055,7 +3105,6 @@ will perform the following checks:
 
  • The parameter's example field contains a CRN-like value (e.g. "crn:0afd-0138-2636")
  • The parameter's examples field contains an entry containing a CRN-like value, as in this example:
 
    -
    
 components:
   parameters:
     ThingIdParam:
@@ -3068,13 +3117,16 @@ components:
       examples:
         crn_example:
           value: 'crn:0afd-0138-2636'
+
 
  • The parameter schema's example field contains a CRN-like value (e.g. "crn:0afd-0138-2636")
  • The parameter's description field contains either "CRN" or "Cloud Resource Name"
  • The parameter schema's description field contains either "CRN" or "Cloud Resource Name"
    • 
 These checks are logically OR'd together, so that if any one or more of these checks
-are true for a particular parameter, then a warning is raised for that parameter. 
+are true for a particular parameter, then a warning is raised for that parameter.
+
    
+
@@ -3085,7 +3137,7 @@ are true for a particular parameter, then a warning is raised for that parameter
 
-
+
    
 
    
 Rule id:
 
 
 
 
 
 
    
 
    
 Severity:oas3
 
    
 
    Non-compliant example:Non-compliant example:
 
 
     components:
@@ -3128,6 +3180,7 @@ components:
 
 
 ### ibm-no-default-for-required-parameter
+
 
@@ -3146,7 +3199,7 @@ components:
 
-
+
    
 
    
 Rule id:oas3
 
    
 
    Non-compliant example:Non-compliant example:
 
 
     components:
@@ -3188,6 +3241,7 @@ components:
 
 
 ### ibm-no-duplicate-description-with-ref-sibling
+
 
@@ -3228,6 +3282,7 @@ the first and next page of results, respectively.
 
    Starting with OpenAPI 3.0, one can no longer use this pattern.  If a schema definition contains the $ref attribute,
 then no other attributes are allowed to be defined alongsize it.   So to work around this restriction, 
 API authors typically use the "ref sibling" allOf pattern.   The above example might look like this:
+
     components:
   schemas:
@@ -3259,6 +3314,7 @@ second allOf list element.  Both are considered to be examples of the "ref sibli
 
    This rule specifically looks for instances of this pattern where the overridden description is the same as the
 description defined within the referenced schema, thus making the use of the "ref sibling" pattern unnecessary.
 Here is an example of this:
+
    
 
     components:
   schemas:
@@ -3289,7 +3345,7 @@ components:
 
    
-
+
    
 
    
 Rule id:
 oas3
 
    
 
    Non-compliant example:Non-compliant example:
 
 
     components:
@@ -3338,6 +3394,7 @@ components:
 
 
 ### ibm-no-if-modified-since-header
+
 
@@ -3349,6 +3406,8 @@ components:
 recommends against the use of the If-Modified-Since and If-Unmodified-Since header parameters.
 Operations should support If-Match and If-None-Match headers instead.
 
    This rule warns about operations that support the If-Modified-Since header parameter.
+
    
+
@@ -3422,6 +3481,7 @@ paths:
 
 
 ### ibm-no-if-unmodified-since-header
+
 
    
 
    
 Rule id:
 
    
 
    
 Severity:
    
@@ -3433,6 +3493,8 @@ paths:
 recommends against the use of the If-Modified-Since and If-Unmodified-Since header parameters.
 Operations should support If-Match and If-None-Match headers instead.
 
    This rule warns about operations that support the If-Unmodified-Since header parameter.
+
    
+
@@ -3498,6 +3560,7 @@ paths:
 
 
 ### ibm-no-nullable-properties
+
 
    
 
    
 Rule id:
 
    
 
    
 Severity:
    
@@ -3521,7 +3584,7 @@ This rule ensures that nullable properties are not defined elsewhere.
 
-
+
    
 
    
 Rule id:oas3
 
    
 
    Non-compliant example:Non-compliant example:
 
 
     components:
@@ -3627,6 +3690,7 @@ paths:
 
 
 ### ibm-no-operation-requestbody
+
 
@@ -3655,6 +3719,7 @@ This rule ensures that these operations do not define a requestBody
-
+
    
 
    
 Rule id:
 This rule supports a configuration that specifies the set of HTTP methods that are checked
 for a requestBody.
 
    The default configuration object provided with the rule is:
+
    
 
     {
   httpMethods: ['delete', 'get', 'head', 'options']
@@ -3665,6 +3730,7 @@ for a requestBody.
 custom ruleset and modify the configuration such that the value of the httpMethods field 
 specifies the desired set of HTTP methods to be checked.
 For example, to enforce the rule for DELETE, HEAD and OPTIONS operations, the configuration object would look like this:
+
    
 
     {
   httpMethods: ['delete', 'head', 'options']
@@ -3673,7 +3739,7 @@ For example, to enforce the rule for DELETE, HEAD and OPTIONS operations, the co
 
    		
 
    
 
    Non-compliant example:Non-compliant example:
 
 
     paths:
@@ -3729,6 +3795,7 @@ paths:
 
 
 ### ibm-no-optional-properties-in-required-body
+
 
@@ -3753,7 +3820,7 @@ This rule is deprecated.  Please use the ibm-no-required-properties-in-opt
 
-
+
    
 
    
 Rule id:oas3
 
    
 
    Non-compliant example:Non-compliant example:
 
 
     paths:
@@ -3790,6 +3857,7 @@ paths:
 
 
 ### ibm-no-ref-in-example
+
 
@@ -3808,7 +3876,7 @@ paths:
 
-
+
    
 
    
 Rule id:oas3
 
    
 
    Non-compliant example:Non-compliant example:
 
 
     paths:
@@ -3850,6 +3918,7 @@ paths:
 
 
 ### ibm-no-required-properties-in-optional-body
+
 
@@ -3872,7 +3941,7 @@ request body to be required.
 
-
+
    
 
    
 Rule id:oas3
 
    
 
    Non-compliant example:Non-compliant example:
 
 
     paths:
@@ -3909,6 +3978,7 @@ paths:
 
 
 ### ibm-no-space-in-example-name
+
 
@@ -3927,7 +3997,7 @@ paths:
 
-
+
    
 
    
 Rule id:oas3
 
    
 
    Non-compliant example:Non-compliant example:
 
 
     paths:
@@ -3978,6 +4048,7 @@ paths:
 
 
 ### ibm-no-superfluous-allof
+
 
@@ -3996,7 +4067,7 @@ paths:
 
-
+
@@ -4026,6 +4097,7 @@ components:
 
 
 ### ibm-no-unsupported-keywords
+
 
    
 
    
 Rule id:oas3
 
    
 
    Non-compliant example:Non-compliant example:
 
 
     components:
@@ -4006,7 +4077,7 @@ components:
         foo_ref:
           allOf:
             - $ref: '#/components/schemas/Foo'
-<
    
+
     		
 
    
 
    
@@ -4047,7 +4119,7 @@ by IBM's SDK-related tooling - specifically the jsonSchemaDialect a
 
-
+
    
 
    
 Rule id:oas3_1
 
    
 
    Non-compliant example:Non-compliant example:
 
 
     openapi: 3.1.0
@@ -4096,6 +4168,7 @@ info:
 
 
 ### ibm-openapi-tags-used
+
 
@@ -4114,7 +4187,7 @@ info:
 
-
+
    
 
    
 Rule id:oas3
 
    
 
    Non-compliant example:Non-compliant example:
 
 
     tags:
@@ -4157,6 +4230,7 @@ paths:
 
 
 ### ibm-operation-responses
+
 
@@ -4176,7 +4250,7 @@ paths:
 
-
+
    
 
    
 Rule id:oas3_1
 
    
 
    Non-compliant example:Non-compliant example:
 
 
     paths:
@@ -4213,6 +4287,7 @@ paths:
 
 
 ### ibm-operation-summary
+
 
@@ -4232,7 +4307,7 @@ paths:
 
-
+
    
 
    
 Rule id:oas3
 
    
 
    Non-compliant example:Non-compliant example:
 
 
     paths:
@@ -4260,6 +4335,7 @@ paths:
 
 
 ### ibm-operation-summary-length
+
 
@@ -4280,7 +4356,7 @@ per guidance in the 1]
 to enforce the desired case convention for operationId values.
 
    The default configuration object provided in the rule definition is:
+
     {
   type: 'snake'
@@ -4344,6 +4422,7 @@ to enforce the desired case convention for operationId values.
 custom ruleset and modify the configuration such that the value of the type field 
 specifies the desired case convention.
 For example, to enforce camel case for operation ids, the configuration object would look like this:
+
    
 
     {
   type: 'camel'
@@ -4352,7 +4431,7 @@ For example, to enforce camel case for operation ids, the configuration object w
 
 
    
-
+
    
 
    
 Rule id:
 
    
 
    Non-compliant example:Non-compliant example:
 
 
     paths:
@@ -4377,6 +4456,7 @@ paths:
 
 
 ### ibm-operationid-naming-convention
+
 
@@ -4390,12 +4470,14 @@ when deciding on an operationId for the POST /v1/things operation.
 Likewise, for the GET /v1/things/{thing_id} operation, we might prefer
 get_thing over retrieve_thing for the operationId.
 
    This rule will analyze the operations, looking for operationId values that are not using the recommended verbs. Furthermore it can also validate the complete name of the operation id by comparing it to the path segments.
+
    
-
+
    
 
    
 Rule id:
 
 
    
 
    
 Configuration:
 This rule can be configured to validate the complete name of the operation id, or only the verb it begins with.
 
    The default configuration object provided in the rule definition is:
+
    
 
     {
   strict: true
@@ -4404,6 +4486,7 @@ Likewise, for the GET /v1/things/{thing_id} operation, we might pre
 
    To switch off the complete name validation and only validate the verbs the operation ids begin with, you'll need to
 replace this rule with a new rule within your
 custom ruleset and modify the configuration such that the value of the strict field to false
+
    
 
     {
   strict: false
@@ -4420,7 +4503,7 @@ custom ruleset and modify the configuration such that the value of the oas3
    		
 
    
 
    Non-compliant example:Non-compliant example:
 
 
     paths:
@@ -4467,6 +4550,7 @@ paths:
 
 
 ### ibm-pagination-style
+
 
@@ -4477,17 +4561,19 @@ paths:
 
-
+
    
 
    
 Rule id:This rule verifies that list-type operations implement pagination correctly per the guidelines in the 
 API Handbook.
 
    An operation is recognized as a paginated list-type operation if all of the following are true:
+
    
 
      
 
    • The path doesn't end in a path segment that is a path parameter reference
 (e.g. /v1/things vs /v1/things/{thing_id}).
      • 
 
    • The operation is a get.
      • 
 
    • The operation's response schema is an object containing an array property.
      • 
 
    • The operation defines either the offset query parameter or a page-token type
-query parameter whose name is one of the following: start(preferred), 
+query parameter whose name is one of the following: start(preferred),
 token, cursor, page, or page_token.
      • 
 
    
 
    If an operation is recognized as a paginated list-type operation, then the following checks are
 performed:
+
    
 
 
    To disable the case convention checks for a particular parameter type, simply remove
 the entry for that parameter type from the configuration object.  
+
    
 
    If you want to use a different configuration for this rule other than the default configuration
 mentioned above, you'll need to
 replace this rule with a new rule within your
 custom ruleset and modify the configuration appropriately for your needs.
 For example, to disable the case convention checks on header parameter names, while enforcing camel-case conventions
 on query and path parameter names, the configuration object would look like this:
+
    
 
     {
   query: {
@@ -4634,7 +4724,7 @@ on query and path parameter names, the configuration object would look like this
 
    		
 
    
 
    Non-compliant example:Non-compliant example:
 
 
     components:
@@ -4677,6 +4767,7 @@ components:
 
 
 ### ibm-parameter-description
+
 
@@ -4695,7 +4786,7 @@ components:
 
-
+
    
 
    
 Rule id:oas3
 
    
 
    Non-compliant example:Non-compliant example:
 
 
     components:
@@ -4737,6 +4828,7 @@ components:
 
 
 ### ibm-parameter-order
+
 
@@ -4757,7 +4849,7 @@ listed first, then any optional parameters.
 
-
+
    
 
    
 Rule id:oas3
 
    
 
    Non-compliant example:Non-compliant example:
 
 
     paths:
@@ -4818,6 +4910,7 @@ paths:
 
 
 ### ibm-parameter-schema-or-content
+
 
@@ -4836,7 +4929,7 @@ paths:
 
-
+
    
 
    
 Rule id:oas3
 
    
 
    Non-compliant example:Non-compliant example:
 
 
     parameters:
@@ -4863,6 +4956,7 @@ parameters:
 
 
 ### ibm-patch-request-content-type
+
 
@@ -4874,6 +4968,7 @@ parameters:
 recommends that PATCH operations contain request bodies that support only content types
 application/json-patch+json and application/merge-patch+json.
 
    This rule verifies that each PATCH operation complies with this recommendation.
+
    
@@ -4885,7 +4980,7 @@ recommends that PATCH operations contain request bodies that support only conten
 
-
+
    
 
    
 Rule id:
 
 
    
 
    oas3
 
    
 
    Non-compliant example:Non-compliant example:
 
 
     paths:
@@ -4932,6 +5027,7 @@ paths:
 
 
 ### ibm-path-segment-casing-convention
+
 
@@ -4958,6 +5054,7 @@ to enforce a different case convention if desired.
 custom ruleset and modify the configuration such that the value of the type field 
 specifies the desired case convention.
 For example, to enforce camel case for path segments, the configuration object would look like this:
+
     {
   type: 'camel'
@@ -4966,7 +5063,7 @@ For example, to enforce camel case for path segments, the configuration object w
 
 
    
-
+
    
 
    
 Rule id:
 
    
 
    Non-compliant example:Non-compliant example:
 
 
     paths:
@@ -4987,6 +5084,7 @@ paths:
 
 
 ### ibm-pattern-properties
+
 
@@ -4998,9 +5096,13 @@ paths:
 within a schema:
 
      
 
    • The patternProperties field must be an object with exactly one entry.
+
      • 
 
    • The patternProperties and additionalProperties fields are mutually exclusive within a particular schema.
+
      • 
 
    • The patternProperties field must contain a regular expression anchored by ^ and $.
+
      • 
 
    
+
@@ -5011,7 +5113,7 @@ within a schema:
 
-
+
    
 
    
 Rule id:
 
    
 
    
 Severity:oas3_1
 
    
 
    Non-compliant example:Non-compliant example:
 
 
     components:
@@ -5056,6 +5158,7 @@ components:
 
 
 ### ibm-precondition-headers
+
 
@@ -5076,7 +5179,7 @@ For more details, please see the API Handbook section on
 
-
+
    
 
    
 Rule id:oas3
 
    
 
    Non-compliant example:Non-compliant example:
 
 
     paths:
@@ -5131,6 +5234,7 @@ paths:
 
 
 ### ibm-prefer-token-pagination
+
 
@@ -5149,7 +5253,7 @@ paths:
 
-
+
    
 
    
 Rule id:oas3
 
    
 
    Non-compliant example:Non-compliant example:
 
 
     paths:
@@ -5231,6 +5335,7 @@ paths:
 
 
 ### ibm-property-attributes
+
 
@@ -5274,7 +5379,7 @@ paths:
 
-
+
    
 
    
 Rule id:oas3
 
    
 
    Non-compliant example:Non-compliant example:
 
 
     components:
@@ -5309,6 +5414,7 @@ components:
 
 
 ### ibm-property-casing-convention
+
 
@@ -5334,6 +5440,7 @@ that is the appropriate configuration to be used by Spectral's casing()1]
 to enforce the desired case convention for property names.
 
    The default configuration object provided in the rule definition is:
+
    
 
     {
   type: 'snake'
@@ -5344,6 +5451,7 @@ to enforce the desired case convention for property names.
 custom ruleset and modify the configuration such that the value of the type field 
 specifies the desired case convention.
 For example, to enforce camel case for property names, the configuration object would look like this:
+
    
 
     {
   type: 'camel'
@@ -5352,7 +5460,7 @@ For example, to enforce camel case for property names, the configuration object
 
 
    
-
+
    
 
    
 Rule id:
    
 
    Non-compliant example:Non-compliant example:
 
 
     components:
@@ -5387,6 +5495,7 @@ components:
 
 
 ### ibm-property-consistent-name-and-type
+
 
@@ -5409,7 +5518,7 @@ throughout the API definition.
 
-
+
    
 
    
 Rule id:oas3
 
    
 
    Non-compliant example:Non-compliant example:
 
 
     components:
@@ -5454,6 +5563,7 @@ components:
 
 
 ### ibm-property-description
+
 
@@ -5472,7 +5582,7 @@ components:
 
-
+
    
 
    
 Rule id:oas3
 
    
 
    Non-compliant example:Non-compliant example:
 
 
     components:
@@ -5509,6 +5619,7 @@ components:
 
 
 ### ibm-redirect-response-body
+
 
@@ -5523,6 +5634,7 @@ components:
 
  • For a 30x response the code field must contain one of the following values for redirect code and nothing else: forwarded, resolved, moved, remote_region, remote_account, version_mismatch.
    • References:
+
    
@@ -5537,7 +5649,7 @@ components:
 
-
+
-
+
    
 
    
 Rule id:
 
 
 oas3
 
    
 
    Compliant example:Compliant example:
 
 
     paths:
@@ -5569,7 +5681,7 @@ paths:
 
    		
 
    
 
    Non-compliant example:Non-compliant example:
 
 
     paths:
@@ -5592,6 +5704,7 @@ paths:
 
 
 ### ibm-ref-pattern
+
 
@@ -5603,6 +5716,7 @@ paths:
 the type of object it references.  For example, a reference to a schema should follow the pattern 
 #/components/schemas/<schema-name>.
 
    Here is the full set of valid patterns for $ref values:
+
      
 
    • #/components/callbacks/<name>
      • 
 
    • #/components/examples/<name>
      • 
@@ -5632,7 +5746,7 @@ proper locations within the API definition's componentsfield.
 
    
-
+
    
 
    
 Rule id:
 oas3
 
    
 
    Non-compliant example:Non-compliant example:
 
 
     components:
@@ -5674,6 +5788,7 @@ components:
 
 
 ### ibm-request-and-response-content
+
 
@@ -5692,7 +5807,7 @@ components:
 
-
+
    
 
    
 Rule id:oas3
 
    
 
    Non-compliant example:Non-compliant example:
 
 
     responses:
@@ -5718,6 +5833,7 @@ responses:
 
 
 ### ibm-requestbody-is-object
+
 
@@ -5736,7 +5852,7 @@ responses:
 
-
+
    
 
    
 Rule id:oas3
 
    
 
    Non-compliant example:Non-compliant example:
 
 
     requestBody:
@@ -5766,6 +5882,7 @@ requestBody:
 
 
 ### ibm-requestbody-name
+
 
@@ -5784,6 +5901,7 @@ way to infer a logical name for the operation's body parameter.
 that the x-codegen-request-body-name extension is set on the operation.
 

    This rule is disabled by default. Enable it in your Spectral config file to utilize this validation.
+
    
@@ -5795,7 +5913,7 @@ that the x-codegen-request-body-name extension is set on the operat
 
-
+
    
 
    
 Rule id:
 
 
 
    
 
    oas3
 
    
 
    Non-compliant example:Non-compliant example:
 
 
     paths:
@@ -5833,6 +5951,7 @@ paths:
 
 
 ### ibm-required-array-properties-in-response
+
 
@@ -5856,7 +5975,7 @@ and not optional.
 
-
+
    
 
    
 Rule id:oas3
 
    
 
    Non-compliant example:Non-compliant example:
 
 
     paths:
@@ -5913,6 +6032,7 @@ components:
 
 
 ### ibm-required-enum-properties-in-response
+
 
@@ -5936,7 +6056,7 @@ and not optional.
 
-
+
    
 
    
 Rule id:oas3
 
    
 
    Non-compliant example:Non-compliant example:
 
 
     paths:
@@ -6008,10 +6128,11 @@ components:
 
 
 ### ibm-resource-response-consistency
+
 
-
+
@@ -6026,7 +6147,7 @@ components:
 
-
+
    
 
    
 Rule id:ibm-requestbody-nameibm-resource-response-consistency
 
    
 
    
 Description:oas3
 
    
 
    Non-compliant example:Non-compliant example:
 
 
     paths:
@@ -6091,6 +6212,7 @@ paths:
 
 
 ### ibm-response-status-codes
+
 
@@ -6121,6 +6243,7 @@ or a 202 - Accepted status code.
 operationId starts with "create" or the operation is a POST request and there is another path
 present in the API that is similar to the path of the "create" operation, but with a trailing path parameter reference.
 For example, "process_things" would be considered a "create"-type operation:
+
       paths:
     '/v1/things':
@@ -6139,14 +6262,14 @@ but "handle_things" would not:
         operationId: handle_things
         ...
 
    
-The difference being that with the "handle_things" operation, there is no corresponding path
-with a trailing path parameter reference that would give us a hint that "handle_things" is a create-type operation.
-
+
  • The difference being that with the "handle_things" operation, there is no corresponding path
+with a trailing path parameter reference that would give us a hint that "handle_things" is a create-type operation.
  • An operation that returns a 202 - Accepted status code should not return any other
 success (2xx) status codes. This is because an operation should be unambiguous in terms of whether or not
 it is a synchronous or asynchronous operation.
    • 
-
    References: 
+
    References:
+
    
-
+
    
 
    
 Rule id:
 
 
 
 oas3
 
    
 
    Non-compliant example:Non-compliant example:
 
 
     paths:
@@ -6214,6 +6337,7 @@ paths:
 
 
 ### ibm-schema-casing-convention
+
 
@@ -6242,6 +6366,7 @@ that is the appropriate configuration to be used by Spectral's pattern()1]
 to enforce the desired case convention for schema name values.
 
    The default configuration object provided in the rule definition is:
+
    
 
     {
   match: '/^[A-Z]+[a-z0-9]+([A-Z]+[a-z0-9]*)*$/'
@@ -6252,6 +6377,7 @@ to enforce the desired case convention for schema name values.
 custom ruleset and modify the configuration such that the value of the match field 
 specifies the desired case convention.
 For example, to disallow capitalized acronymns for schema names, the configuration object would look like this:
+
    
 
     {
   match: '/^[A-Z][a-z0-9]+([A-Z][a-z0-9]+)*$/'
@@ -6260,7 +6386,7 @@ For example, to disallow capitalized acronymns for schema names, the configurati
 
 
    
-
+
    
 
    
 Rule id:
    
 
    Non-compliant example:Non-compliant example:
 
 
     components:
@@ -6289,6 +6415,7 @@ components:
 
 
 ### ibm-schema-description
+
 
@@ -6307,7 +6434,7 @@ components:
 
-
+
    
 
    
 Rule id:oas3
 
    
 
    Non-compliant example:Non-compliant example:
 
 
     components:
@@ -6339,6 +6466,7 @@ components:
 
 
 ### ibm-schema-keywords
+
 
@@ -6364,6 +6492,7 @@ in an OpenAPI 3.1.x document. The allowable keywords are configurable (see the <
 
-
+
    
 
    
 Rule id:This rule supports a configuration object that specifies the set of keywords that are allowed within a schema
 or schema property.
 
    The default configuration object provided with the rule is:
+
    
 
     {
   keywordAllowList: [
@@ -6412,6 +6541,7 @@ contains the desired set of keywords to be checked.
 For example, to configure the rule so that uniqueItems and unevaluatedProperties are disallowed, 
 modify the configuration to remove these keywords from the keywordAllowList
 configuration field, like this:
+
    
 
     {
   keywordAllowList: [
@@ -6454,7 +6584,7 @@ configuration field, like this:
 
    		
 
    
 
    Non-compliant example:Non-compliant example:
 
 
     components:
@@ -6490,6 +6620,7 @@ components:
 
 
 ### ibm-schema-naming-convention
+
 
@@ -6512,7 +6643,7 @@ The rule checks the names of collection schemas, resource collection element sch
 
-
+
    
 
    
 Rule id:oas3
 
    
 
    Non-compliant example:Non-compliant example:
 
 
     paths:
@@ -6561,6 +6692,7 @@ paths:
 
 
 ### ibm-schema-type
+
 
@@ -6583,7 +6715,7 @@ Schemas and schema properties should have a non-empty type field.
 
-
+
    
 
    
 Rule id:oas3
 
    
 
    Non-compliant example:Non-compliant example:
 
 
     components:
@@ -6611,6 +6743,7 @@ components:
 
 
 ### ibm-schema-type-format
+
 
@@ -6657,7 +6790,7 @@ The following table defines the valid combinations:
 
-
+
    
 
    
 Rule id:oas3
 
    
 
    Non-compliant example:Non-compliant example:
 
 
     components:
@@ -6704,6 +6837,7 @@ components:
 
 
 ### ibm-sdk-operations
+
 
@@ -6724,7 +6858,7 @@ extension, using t
 
-
+
@@ -6739,6 +6873,7 @@ n/a
 
 
 ### ibm-securityscheme-attributes
+
 
    
 
    
 Rule id:oas3
 
    
 
    Non-compliant example:Non-compliant example:
 
 n/a
 
    
@@ -6749,6 +6884,7 @@ n/a
 
-
+
    
 
    
 Rule id:Performs a series of validations on the content within security schemes to ensure they comply
 with the constraints outlined in the OpenAPI Specification.
 
    Specifically, the rule will perform these checks:
+
    
 
      
 
    1. Each security scheme must specify the type property. Valid values for the type property are:
 
        
@@ -6770,13 +6906,13 @@ Valid values for the in property are:
 
 
      • A security scheme with type oauth2 must specify the flows property.
 
        Furthermore, the flows property must be an object that defines at least one of the following keys:
+
        
 
          
 
        • implicit
          • 
 
        • authorizationcode
          • 
 
        • clientCredentials
          • 
 
        • password
          • 
 
        
-
        
 
        An implicit oauth2 flow must specify the scopes and authorizationUrl properties.
        
 
        A password or clientCredentials oauth2 flow must specify the scopes and tokenUrl properties.
        
 
        An authorizationCode oauth2 flow must specify the scopes, authorizationUrl, and tokenUrl properties.
        
@@ -6795,7 +6931,7 @@ Valid values for the in property are:
 
    		oas3
 
    
 
    Non-compliant example:Non-compliant example:
 
 
     components:
@@ -6845,6 +6981,7 @@ components:
 
 
 ### ibm-securityschemes
+
 
@@ -6854,6 +6991,7 @@ components:
 
-
+
    
 
    
 Rule id:Description:
 Verifies the security schemes and security requirement objects.
 
    Specifically, the rule will perform these checks:
+
    
 
      
 
    1. The name used within a security requirement object must correspond to a
 security scheme that is properly defined in "components.securitySchemes".
@@ -6882,7 +7020,7 @@ scopes, then its scopes array MUST be empty.
 
    		oas3
 
    
 
    Non-compliant example:Non-compliant example:
 
 
     paths:
@@ -6922,6 +7060,7 @@ components:
 
 
 ### ibm-server-variable-default-value
+
 
@@ -6940,7 +7079,7 @@ components:
 
-
+
    
 
    
 Rule id:oas3
 
    
 
    Non-compliant example:Non-compliant example:
 
 
     servers:
@@ -6974,6 +7113,7 @@ servers:
 
 
 ### ibm-string-attributes
+
 
@@ -6985,9 +7125,10 @@ servers:
 fields in order to clearly define the set of valid values for the property.
 [1].
 
    Note that these checks are bypassed for the following scenarios:
+
      
 
    • All checks are bypassed for string schemas that contain an enum field.
      • 
-
    • The check for the pattern field is bypassed if format is set to 
+
    • The check for the pattern field is bypassed if format is set to
 binary, byte, date, date-time, or url.
      • 
 
    • The check for the minLength field is bypassed if format is set to
 date, identifier, or url.
      • 
@@ -6996,6 +7137,7 @@ fields in order to clearly define the set of valid values for the property.
 
      This rule also checks non-string schema properties to make sure they do not define the
 pattern, minLength and maxLength fields since these fields are applicable
 only for string schemas.
+
      
 
 
    
@@ -7007,7 +7149,7 @@ only for string schemas.
 
-
+
    
 
    
 Rule id:
 
    
 
    oas3
 
    
 
    Non-compliant example:Non-compliant example:
 
 
     components:
@@ -7046,6 +7188,7 @@ components:
 
 
 ### ibm-success-response-example
+
 
@@ -7066,7 +7209,7 @@ within each response content field entry, in order to aid in the ge
 
-
+
    
 
    
 Rule id:oas3
 
    
 
    Non-compliant example:Non-compliant example:
 
 
     responses:
@@ -7092,6 +7235,7 @@ responses:
           example: 'example string'
 
    
 
    Alternatively, the example may be provided as a sibling to the schema object.
+
    
 
     responses:
   200:
@@ -7100,13 +7244,14 @@ responses:
         schema:
           type: string
         example: 'example string'
-
    +
    
 
    		
 
    
 
    
 
 
 ### ibm-summary-sentence-style
+
 
@@ -7126,7 +7271,7 @@ not have a trailing period.
-
+
    
 
    
 Rule id:
 oas3
 
    
 
    Non-compliant example:Non-compliant example:
 
 
     paths:
@@ -7155,6 +7300,7 @@ paths:
 
 
 ### ibm-unevaluated-properties
+
 
@@ -7165,6 +7311,7 @@ paths:
 
@@ -7175,7 +7322,7 @@ is set on a schema, then it is set to the value false (i.e. disable
 
-
+
    
 
    
 Rule id:This rule ensures that unevaluatedProperties is not enabled within a schema.
 It checks to make sure that if the unevaluatedProperties field
 is set on a schema, then it is set to the value false (i.e. disabled).
+
 
    
 
    
 Severity:oas3_1
 
    
 
    Non-compliant example:Non-compliant example:
 
 
     components:
@@ -7215,6 +7362,7 @@ components:
 
 
 ### ibm-unique-parameter-request-property-names
+
 
@@ -7234,14 +7382,17 @@ This means that, instead of representing the operation's request body as a singl
 will expose each of the properties defined in the operation's request body
 schema such that they appear to be individual operation parameters.   This optimization makes it easier for
 an SDK user to construct an instance of the request body schema (class, struct, etc.) when invoking the operation.
+
    Because the request body schema properties are exposed as operation parameters, the generator must detect if there are
 any name collisions between these schema properties and the operation's other parameters.
 The generator will rename the request body schema properties if any collisions are detected,
 but the names computed by the generator are not optimal from a usability standpoint, so it's better for the API
 to be defined such that the name collisions are avoided altogether.
+
    This validation rule checks each operation for name collisions between the operation's parameters and its request body
 schema properties.  An error is logged for each collision.  Each of these errors should be addressed by renaming either 
 the parameter or request body schema property to avoid the collision.
+
    
@@ -7253,7 +7404,7 @@ the parameter or request body schema property to avoid the collision.
 
-
+
    
 
    
 Rule id:
 
 
 
 
    
 
    oas3
 
    
 
    Non-compliant example:Non-compliant example:
 
 
     paths:
@@ -7332,6 +7483,7 @@ paths:
 
 
 ### ibm-use-date-based-format
+
 
@@ -7355,7 +7507,7 @@ the example value provided for a schema or property.
 
-
+
    
 
    
 Rule id:oas3
 
    
 
    Non-compliant example:Non-compliant example:
 
 
     Resource
@@ -7392,6 +7544,7 @@ Resource
 
 
 ### ibm-valid-path-segments
+
 
@@ -7414,7 +7567,7 @@ For example, the path /v1/foos/_{foo_id}_ is invalid and should pro
 
-
+
    
 
    
 Rule id:oas3
 
    
 
    Non-compliant example:Non-compliant example:
 
 
     paths:
@@ -7445,6 +7598,7 @@ paths:
 
 
 ### ibm-valid-schema-example
+
 
@@ -7465,7 +7619,7 @@ is a valid instance of that schema. Note that this rule is an alternative to `oa
 
-
+
    
 
    
 Rule id:oas3
 
    
 
    Non-compliant example:Non-compliant example:
 
 
     components:
@@ -7492,6 +7646,7 @@ components:
 
 
 ### ibm-well-defined-dictionaries
+
 
@@ -7516,7 +7671,7 @@ components:
 
-
+
    
 
    
 Rule id:oas3
 
    
 
    Non-compliant example:Non-compliant example:
 
 
     components:
diff --git a/index.html b/index.html
new file mode 100644
index 00000000..b544e2ac
--- /dev/null
+++ b/index.html
@@ -0,0 +1,13 @@
+---
+---
+
+
+
+  
+  
+  IBM OpenAPI Validator
+
+
+  
    Redirecting to IBM Cloud Validation Ruleset…
    
+
+