Clarify how Schema Objs require full-doc parsing

JSON Schema draft 2020-12 includes numerous keywords that require
parsing the entire document prior to deeming a reference unresolvable.
This makes that more clear and outlines several approaches.

The practice of embedding OpenAPI fragments in other formats is
deemed to have implementation-defined (non-interoperable) behavior,
as the potential complications that might arise are not predictable.

Author: handrews

versions/3.1.1.md

@@ -140,6 +140,22 @@ An OpenAPI Description (OAD) MAY be made up of a single document or be divided i
 
 It is RECOMMENDED that the entry OpenAPI document be named: `openapi.json` or `openapi.yaml`.
 
+#### <a name="parsingDocuments">Parsing Documents
+
+In order to properly handle [Schema Objects](#schemaObject), OAS 3.1 inherits the parsing requirements of [JSON Schema draft 2020-12 §9](https://datatracker.ietf.org/doc/html/draft-bhutton-json-schema-00#section-9), with appropriate modifications regarding base URIs as specified in [Relative References In URIs](#relativeReferencesURI).
+
+This includes a requirement to parse complete documents before deeming a Schema object reference to be unresolvable, in order to detect keywords that might provide the reference target or impact the determination of the appropriate base URI.
+
+Implementations MAY support complete-document parsing in any of the following ways:
+
+* Detecting OpenAPI or JSON Schema documents using media types
+* Detecting OpenAPI documents through the root `openapi` property
+* Detecting JSON Schema documents through detecting keywords or otherwise successfully parsing the document in accordance with the JSON Schema specification
+* Detecting a document containing a referenceable Object at its root based on the expected type of the reference
+* Allowing users to configure the type of documents that might be loaded due to a reference to a non-root Object
+
+Embedding fragments of OpenAPI content in other formats can produce unexpected interactions among the enclosing format, the OAS, and JSON Schema.  While implementations MAY choose to support such arrangements, the resulting behavior is _implementation defined_.  This includes parsing fragments of OpenAPI out of a complete OpenAPI document while treating the rest of the document as arbitrary JSON or YAML.
+
 #### <a name="structuralInteroperability"></a>Structural Interoperability
 
 When parsing an OAD, JSON or YAML objects are parsed into specific Objects (such as [Operation Objects](#operationObject), [Response Objects](#responseObject), [Reference Objects](#referenceObject), etc.) based on the parsing context.  Depending on how references are arranged, a given JSON or YAML object can be parsed in multiple different contexts: