understand openapi format(s) when parsing documents

[karenetheridge]

Today, constructing a ::Document object with a non-schema entity will "work" (there are examples in the test suite of this, e.g. https://github.com/json-schema-org/JSON-Schema-Test-Suite/blob/2.0.0/remotes/subSchemas.json), but since the structure at the top level is not a schema, traversal will not proceed and $id and $anchor properties within will not be detected and indexed as resources to be used for URI resolution.

Implement some sort of mechanism (either autodection, or perhaps with a ::Document constructor option) to recognize the various openapi format(s) that come after draft2019-09 so we can properly traverse these documents. Likely this will involve defining a Vocabulary class that is capable of recognizing how subschemas are embedded in the document.

[karenetheridge]

public interfaces that will help integration with openapi-using web applications:

• given an operationId, find the full spec for this endpoint (path, query, request, response..)
• given an operationId and a HTTP::Request or Mojo::Request, validate the request
• "" ::Response, validate the response

[karenetheridge]

subclassing ::Document would work.

• override the 'dialect' default, to the vocabularies that know how to parse this document
• maintain a list of json pointers (or references?) to all the actual json schemas within?
• resource identifiers are not necessarily json schemas
• add a 'traverse' method that calls evaluator->traverse?

[karenetheridge]

This is now in the bailiwick of JSON::Schema::Modern::Document::OpenAPI.