anchor.diff:  the various <<Documentation Mechanisms>>, so that the implementing framework can
   perform a global replacement of the keys with the language-specific text that
   matches the `Accept-Language` request for the `/openapi` endpoint.  A cache of
  -processed languages can be kept to improve performance. 
  +processed languages can be kept to improve performance.
  
positive.code: = MicroProfile OpenAPI Specification
  
  == Introduction
  
  == Architecture
  
  == OpenAPI Endpoint
  
  === Overview
  A fully processed and valid OpenAPI document must be available at the root
  URL `/openapi`, as a `HTTP GET` operation.
  
  For example, `GET http://myHost:myPort/openapi`.
  
  This document represents the result of the applied <<Processing rules>>.
  
  === Content format
  The default `Content-Type` of the `/openapi` endpoint is `application/yaml`.
  
  Vendors must also support the type `application/json` if requested via the
  `Accept` header.
  
  === Query parameters
  No query parameter are required for the `/openapi` endpoint.  However, one
  suggested but optional query parameter for vendors to support is `format`,
  where the value can be `json`, to facilate the toggle between the default `yaml`
  format and `json` format.
  
  === Context root behaviour
  Vendors are required to ensure that the combination of each global https://github.com/OAI/OpenAPI-Specification/blob/master/versions/3.0.0.md#serverObject[server]
  element and https://github.com/OAI/OpenAPI-Specification/blob/master/versions/3.0.0.md#pathItemObject[pathItem] element resolve to the absolute backend URL of that
  particular path.  If that `pathItem` contains a `servers` element , then this
  list of operation-level `server` elements replaces the global list of servers
  for that particular `pathItem`.
  
  For example:  an application may have an `ApplicationPath` annotation with the
  value of `/`, but is assigned the context root of `/myApp` during deployment. In
  this case, the `server` elements (either global or operation-level) must either
  end with `/myApp` or a corresponding proxy.  Alternatively it is valid, but discouraged, to
  add that context root (`/myApp`) to every `pathItem` defined in that application.
  
  === Multiple applications
  
  The 1.0 version of the MicroProfile OpenAPI specification does not define how
  the `/openapi` endpoint may be partitioned in the event that the MicroProfile
  runtime supports deployment of multiple applications. If an implementation wishes
  to support multiple applications within a MicroProfile runtime, the semantics of
  the `/openapi` endpoint are expected to be the logical AND of all the applications
  in the runtime, which would imply merging multiple OpenAPI documents into a single
  valid document (handling conflicting IDs and unique names).
  
  == Configuration
  === List of configurable items
  === Configuration approaches
  === Vendor specific configuration
  
  == Documentation Mechanisms
  
  === Annotations
  
  ==== Table of annotations
  ==== Usage
  
  ===== Operation
  ===== ApiResponse
  ===== Servers
  ===== Schema
  ===== And more.....
  
  === Models
  ==== How to build OpenAPI model in Java™
  
  === Filter/Interceptor
  ==== Filter mechanics
  
  === Static OpenAPI files
  ==== Location and formats
  ==== Precedence
  
  === Processing rules
  
  The processed document available from `/openapi` is built from a variety of sources,
  which were outlined in the sub-headings of <<Documentation Mechanisms>>.  Vendors
  are required to process these different sources in the following order:
  
  
negative.code: the JAX-RS and OpenAPI annotations from the application will be processed, further
  overriding any conflicting elements from the current model.
  
  == OpenAPI Endpoint
  
  === Overview
  A fully processed and valid OpenAPI document must be available at the root
  URL `/openapi`, as a `HTTP GET` operation.
  
  For example, `GET http://myHost:myPort/openapi`.
  
  This document represents the result of the applied <<Processing rules>>.
  
  === Content format
  The default `Content-Type` of the `/openapi` endpoint is `application/yaml`.
  
  Vendors must also support the type `application/json` if requested via the
  `Accept` header.
  
  === Query parameters
  No query parameter are required for the `/openapi` endpoint.  However, one
  suggested but optional query parameter for vendors to support is `format`,
  where the value can be `json`, to facilate the toggle between the default `yaml`
  format and `json` format.
  
  === Context root behaviour
  Vendors are required to ensure that the combination of each global https://github.com/OAI/OpenAPI-Specification/blob/master/versions/3.0.0.md#serverObject[server]
  element and https://github.com/OAI/OpenAPI-Specification/blob/master/versions/3.0.0.md#pathItemObject[pathItem] element resolve to the absolute backend URL of that
  particular path.  If that `pathItem` contains a `servers` element , then this
  list of operation-level `server` elements replaces the global list of servers
  for that particular `pathItem`.
  
  For example:  an application may have an `ApplicationPath` annotation with the
  value of `/`, but is assigned the context root of `/myApp` during deployment. In
  this case, the `server` elements (either global or operation-level) must either
  end with `/myApp` or a corresponding proxy.  Alternatively it is valid, but discouraged, to
  add that context root (`/myApp`) to every `pathItem` defined in that application.
  
  === Multiple applications
  
  The 1.0 version of the MicroProfile OpenAPI specification does not define how
  the `/openapi` endpoint may be partitioned in the event that the MicroProfile
  runtime supports deployment of multiple applications. If an implementation wishes
  to support multiple applications within a MicroProfile runtime, the semantics of
  the `/openapi` endpoint are expected to be the logical AND of all the applications
  in the runtime, which would imply merging multiple OpenAPI documents into a single
  valid document (handling conflicting IDs and unique names).
  
  
  == Limitations
  