From 15f979dc8a3426450bb4616cc1a36d547c95fa5c Mon Sep 17 00:00:00 2001
From: Darrel Miller <darrel.miller@microsoft.com>
Date: Sun, 16 Jun 2024 11:30:55 -0400
Subject: [PATCH] Removed content from spec as per meeting decision

---
 doc/moonwalk.html                | 827 +------------------------------
 specification/moonwalk-source.md | 491 +-----------------
 2 files changed, 13 insertions(+), 1305 deletions(-)

diff --git a/doc/moonwalk.html b/doc/moonwalk.html
index 8ca36de..18661bf 100644
--- a/doc/moonwalk.html
+++ b/doc/moonwalk.html
@@ -3,19 +3,6 @@
 <meta name="generator" content="ReSpec 35.1.0">
 <meta name="viewport" content="width=device-width, initial-scale=1, shrink-to-fit=no">
 <style>
-.issue-label{text-transform:initial}
-.warning>p:first-child{margin-top:0}
-.warning{padding:.5em;border-left-width:.5em;border-left-style:solid}
-span.warning{padding:.1em .5em .15em}
-.issue.closed span.issue-number{text-decoration:line-through}
-.issue.closed span.issue-number::after{content:" (Closed)";font-size:smaller}
-.warning{border-color:#f11;border-color:var(--warning-border,#f11);border-width:.2em;border-style:solid;background:#fbe9e9;background:var(--warning-bg,#fbe9e9);color:#000;color:var(--text,#000)}
-.warning-title:before{content:"⚠";font-size:1.3em;float:left;padding-right:.3em;margin-top:-.3em}
-li.task-list-item{list-style:none}
-input.task-list-item-checkbox{margin:0 .35em .25em -1.6em;vertical-align:middle}
-.issue a.respec-gh-label{padding:5px;margin:0 2px 0 2px;font-size:10px;text-transform:none;text-decoration:none;font-weight:700;border-radius:4px;position:relative;bottom:2px;border:none;display:inline-block}
-</style>
-<style>
 dfn{cursor:pointer}
 .dfn-panel{position:absolute;z-index:35;min-width:300px;max-width:500px;padding:.5em .75em;margin-top:.6em;font-family:"Helvetica Neue",sans-serif;font-size:small;background:#fff;background:var(--indextable-hover-bg,#fff);color:#000;color:var(--text,#000);box-shadow:0 1em 3em -.4em rgba(0,0,0,.3),0 0 1px 1px rgba(0,0,0,.05);box-shadow:0 1em 3em -.4em var(--tocsidebar-shadow,rgba(0,0,0,.3)),0 0 1px 1px var(--tocsidebar-shadow,rgba(0,0,0,.05));border-radius:2px}
 .dfn-panel:not(.docked)>.caret{position:absolute;top:-9px}
@@ -75,7 +62,7 @@
 .header-wrapper{display:flex;align-items:baseline}
 :is(h2,h3,h4,h5,h6):not(#toc>h2,#abstract>h2,#sotd>h2,.head>h2){position:relative;left:-.5em}
 :is(h2,h3,h4,h5,h6):not(#toch2)+a.self-link{color:inherit;order:-1;position:relative;left:-1.1em;font-size:1rem;opacity:.5}
-:is(h2,h3,h4,h5,h6)+a.self-link::before{content:"§";text-decoration:none;color:var(--heading-text)}
+:is(h2,h3,h4,h5,h6)+a.self-link::before{content:"§";text-decoration:none;color:var(--heading-text)}
 :is(h2,h3)+a.self-link{top:-.2em}
 :is(h4,h5,h6)+a.self-link::before{color:#000}
 @media (max-width:767px){
@@ -88,24 +75,6 @@
 <meta name="color-scheme" content="light">
 <meta name="description" content="The OpenAPI Specification (OAS) defines a standard, programming language-agnostic interface description for HTTP APIs, which allows both humans and computers to discover and understand the capabilities of a service without requiring access to source code, additional documentation, or inspection of network traffic. When properly defined via OpenAPI, a consumer can understand and interact with the remote service with a minimal amount of implementation logic. Similar to what interface descriptions have done for lower-level programming, the OpenAPI Specification removes guesswork in calling a service.">
 <style>
-.hljs{--base:#fafafa;--mono-1:#383a42;--mono-2:#686b77;--mono-3:#717277;--hue-1:#0b76c5;--hue-2:#336ae3;--hue-3:#a626a4;--hue-4:#42803c;--hue-5:#ca4706;--hue-5-2:#c91243;--hue-6:#986801;--hue-6-2:#9a6a01}
-@media (prefers-color-scheme:dark){
-.hljs{--base:#282c34;--mono-1:#abb2bf;--mono-2:#818896;--mono-3:#5c6370;--hue-1:#56b6c2;--hue-2:#61aeee;--hue-3:#c678dd;--hue-4:#98c379;--hue-5:#e06c75;--hue-5-2:#be5046;--hue-6:#d19a66;--hue-6-2:#e6c07b}
-}
-.hljs{display:block;overflow-x:auto;padding:.5em;color:#383a42;color:var(--mono-1,#383a42);background:#fafafa;background:var(--base,#fafafa)}
-.hljs-comment,.hljs-quote{color:#717277;color:var(--mono-3,#717277);font-style:italic}
-.hljs-doctag,.hljs-formula,.hljs-keyword{color:#a626a4;color:var(--hue-3,#a626a4)}
-.hljs-deletion,.hljs-name,.hljs-section,.hljs-selector-tag,.hljs-subst{color:#ca4706;color:var(--hue-5,#ca4706);font-weight:700}
-.hljs-literal{color:#0b76c5;color:var(--hue-1,#0b76c5)}
-.hljs-addition,.hljs-attribute,.hljs-meta-string,.hljs-regexp,.hljs-string{color:#42803c;color:var(--hue-4,#42803c)}
-.hljs-built_in,.hljs-class .hljs-title{color:#9a6a01;color:var(--hue-6-2,#9a6a01)}
-.hljs-attr,.hljs-number,.hljs-selector-attr,.hljs-selector-class,.hljs-selector-pseudo,.hljs-template-variable,.hljs-type,.hljs-variable{color:#986801;color:var(--hue-6,#986801)}
-.hljs-bullet,.hljs-link,.hljs-meta,.hljs-selector-id,.hljs-symbol,.hljs-title{color:#336ae3;color:var(--hue-2,#336ae3)}
-.hljs-emphasis{font-style:italic}
-.hljs-strong{font-weight:700}
-.hljs-link{text-decoration:underline}
-</style>
-<style>
 var{position:relative;cursor:pointer}
 var[data-type]::after,var[data-type]::before{position:absolute;left:50%;top:-6px;opacity:0;transition:opacity .4s;pointer-events:none}
 var[data-type]::before{content:"";transform:translateX(-50%);border-width:4px 6px 0 6px;border-style:solid;border-color:transparent;border-top-color:#222}
@@ -141,20 +110,19 @@
       "title": "CommonMark syntax",
       "href": "https://spec.commonmark.org/",
       "status": "Living Standard",
-      "publisher": "John MacFarlane",
-      "id": "commonmark"
+      "publisher": "John MacFarlane"
     }
   },
-  "publishISODate": "2024-06-10T00:00:00.000Z",
-  "generatedSubtitle": "Unofficial Draft 10 June 2024"
+  "publishISODate": "2024-06-16T00:00:00.000Z",
+  "generatedSubtitle": "Unofficial Draft 16 June 2024"
 }</script>
 <link rel="stylesheet" href="https://www.w3.org/StyleSheets/TR/2021/W3C-UD"></head>
 
-<body class="h-entry"><div class="head">
+<body class="h-entry toc-inline"><div class="head">
     <p class="logos"><a class="logo" href="https://openapis.org/"><img crossorigin="" alt="OpenAPI Initiative" height="48" src="https://raw.githubusercontent.com/OAI/OpenAPI-Style-Guide/master/graphics/bitmap/OpenAPI_Logo_Pantone.png">
   </a></p>
     <h1 id="title" class="title">Moonwalk</h1> 
-    <p id="w3c-state">Unofficial Draft <time class="dt-published" datetime="2024-06-10">10 June 2024</time></p>
+    <p id="w3c-state">Unofficial Draft <time class="dt-published" datetime="2024-06-16">16 June 2024</time></p>
     <details open="">
       <summary>More details about this document</summary>
       <dl>
@@ -225,824 +193,70 @@ <h1 id="title" class="title">Moonwalk</h1>
 
 
 <p>The OpenAPI Specification (OAS) defines a standard, programming language-agnostic interface description for HTTP APIs, which allows both humans and computers to discover and understand the capabilities of a service without requiring access to source code, additional documentation, or inspection of network traffic. When properly defined via OpenAPI, a consumer can understand and interact with the remote service with a minimal amount of implementation logic. Similar to what interface descriptions have done for lower-level programming, the OpenAPI Specification removes guesswork in calling a service.</p>
-</section><nav id="toc"><h2 class="introductory" id="table-of-contents">Table of Contents</h2><ol class="toc"><li class="tocline"><a class="tocxref" href="#current-status-of-document">Current Status of Document</a></li><li class="tocline"><a class="tocxref" href="#abstract">Abstract</a></li><li class="tocline"><a class="tocxref" href="#introduction"><bdi class="secno">1. </bdi>Introduction</a></li><li class="tocline"><a class="tocxref" href="#definitions"><bdi class="secno">2. </bdi>Definitions</a><ol class="toc"><li class="tocline"><a class="tocxref" href="#openapi-document"><bdi class="secno">2.1 </bdi>OpenAPI Document</a></li><li class="tocline"><a class="tocxref" href="#media-types"><bdi class="secno">2.2 </bdi>Media Types</a></li><li class="tocline"><a class="tocxref" href="#http-status-codes"><bdi class="secno">2.3 </bdi>HTTP Status Codes</a></li></ol></li><li class="tocline"><a class="tocxref" href="#conventions"><bdi class="secno">3. </bdi>Conventions</a><ol class="toc"><li class="tocline"><a class="tocxref" href="#oas-version"><bdi class="secno">3.1 </bdi>Versions</a></li><li class="tocline"><a class="tocxref" href="#format"><bdi class="secno">3.2 </bdi>Format</a></li><li class="tocline"><a class="tocxref" href="#data-types"><bdi class="secno">3.3 </bdi>Data Types</a><ol class="toc"><li class="tocline"><a class="tocxref" href="#working-with-binary-data"><bdi class="secno">3.3.1 </bdi>Working With Binary Data</a><ol class="toc"></ol></li></ol></li><li class="tocline"><a class="tocxref" href="#rich-text-formatting"><bdi class="secno">3.4 </bdi>Rich Text Formatting</a></li><li class="tocline"><a class="tocxref" href="#relative-references-in-uris"><bdi class="secno">3.5 </bdi>Relative References in URIs</a></li><li class="tocline"><a class="tocxref" href="#relative-references-in-urls"><bdi class="secno">3.6 </bdi>Relative References in URLs</a></li><li class="tocline"><a class="tocxref" href="#referencing-imports"><bdi class="secno">3.7 </bdi>Referencing Imports</a><ol class="toc"><li class="tocline"><a class="tocxref" href="#using-imported-names"><bdi class="secno">3.7.1 </bdi>Using Imported Names</a></li><li class="tocline"><a class="tocxref" href="#referencing-a-complete-document"><bdi class="secno">3.7.2 </bdi>Referencing a Complete Document</a></li><li class="tocline"><a class="tocxref" href="#locating-and-loading-imported-resources"><bdi class="secno">3.7.3 </bdi>Locating and Loading Imported Resources</a></li><li class="tocline"><a class="tocxref" href="#security-considerations-for-url-retrieval"><bdi class="secno">3.7.4 </bdi>Security Considerations for URL Retrieval</a></li></ol></li><li class="tocline"><a class="tocxref" href="#specification-extensions"><bdi class="secno">3.8 </bdi>Specification Extensions</a></li></ol></li><li class="tocline"><a class="tocxref" href="#document-processing"><bdi class="secno">4. </bdi>Document Processing</a><ol class="toc"><li class="tocline"><a class="tocxref" href="#parsing-documents"><bdi class="secno">4.1 </bdi>Parsing Documents</a></li><li class="tocline"><a class="tocxref" href="#structural-interoperability"><bdi class="secno">4.2 </bdi>Structural Interoperability</a></li><li class="tocline"><a class="tocxref" href="#resolving-implicit-connections"><bdi class="secno">4.3 </bdi>Resolving Implicit Connections</a></li><li class="tocline"><a class="tocxref" href="#undefined-and-implementation-defined-behavior"><bdi class="secno">4.4 </bdi>Undefined and Implementation-Defined Behavior</a></li></ol></li><li class="tocline"><a class="tocxref" href="#openapi-document-structure"><bdi class="secno">5. </bdi>OpenAPI Document Structure</a><ol class="toc"><li class="tocline"><a class="tocxref" href="#general-fixed-fields"><bdi class="secno">5.1 </bdi>General Fixed Fields</a></li><li class="tocline"><a class="tocxref" href="#info-object"><bdi class="secno">5.2 </bdi>Info Object</a><ol class="toc"><li class="tocline"><a class="tocxref" href="#info-object-fixed-fields"><bdi class="secno">5.2.1 </bdi>Fixed Fields</a></li><li class="tocline"><a class="tocxref" href="#info-object-example"><bdi class="secno">5.2.2 </bdi>Info Object Example</a></li></ol></li><li class="tocline"><a class="tocxref" href="#contact-object"><bdi class="secno">5.3 </bdi>Contact Object</a><ol class="toc"><li class="tocline"><a class="tocxref" href="#fixed-fields-0"><bdi class="secno">5.3.1 </bdi>Fixed Fields</a></li><li class="tocline"><a class="tocxref" href="#contact-object-example"><bdi class="secno">5.3.2 </bdi>Contact Object Example</a></li></ol></li><li class="tocline"><a class="tocxref" href="#license-object"><bdi class="secno">5.4 </bdi>License Object</a><ol class="toc"><li class="tocline"><a class="tocxref" href="#fixed-fields-1"><bdi class="secno">5.4.1 </bdi>Fixed Fields</a></li><li class="tocline"><a class="tocxref" href="#license-object-example"><bdi class="secno">5.4.2 </bdi>License Object Example</a></li></ol></li><li class="tocline"><a class="tocxref" href="#components-object"><bdi class="secno">5.5 </bdi>Components Object</a></li><li class="tocline"><a class="tocxref" href="#import-object"><bdi class="secno">5.6 </bdi>Import Object</a><ol class="toc"><li class="tocline"><a class="tocxref" href="#fixed-fields-2"><bdi class="secno">5.6.1 </bdi>Fixed Fields</a></li></ol></li><li class="tocline"><a class="tocxref" href="#api-shape"><bdi class="secno">5.7 </bdi>API Shape</a><ol class="toc"><li class="tocline"><a class="tocxref" href="#shape-fixed-fields"><bdi class="secno">5.7.1 </bdi>Shape Fixed Fields</a></li><li class="tocline"><a class="tocxref" href="#operation-object"><bdi class="secno">5.7.2 </bdi>Operation Object</a><ol class="toc"></ol></li></ol></li><li class="tocline"><a class="tocxref" href="#api-deployment"><bdi class="secno">5.8 </bdi>API Deployment</a><ol class="toc"><li class="tocline"><a class="tocxref" href="#deployment-fixed-fields"><bdi class="secno">5.8.1 </bdi>Deployment Fixed Fields</a></li><li class="tocline"><a class="tocxref" href="#deployment-example"><bdi class="secno">5.8.2 </bdi>Deployment Example</a></li><li class="tocline"><a class="tocxref" href="#deployment-object"><bdi class="secno">5.8.3 </bdi>Deployment Object</a><ol class="toc"></ol></li><li class="tocline"><a class="tocxref" href="#security-scheme-object"><bdi class="secno">5.8.4 </bdi>Security Scheme Object</a><ol class="toc"></ol></li><li class="tocline"><a class="tocxref" href="#credential-object"><bdi class="secno">5.8.5 </bdi>Credential Object</a><ol class="toc"></ol></li><li class="tocline"><a class="tocxref" href="#security-config-object"><bdi class="secno">5.8.6 </bdi>Security Config Object</a><ol class="toc"></ol></li></ol></li></ol></li><li class="tocline"><a class="tocxref" href="#appendix"><bdi class="secno">6. </bdi>Appendix</a></li><li class="tocline"><a class="tocxref" href="#revision-history"><bdi class="secno">A. </bdi>Revision History</a></li><li class="tocline"><a class="tocxref" href="#issue-summary"><bdi class="secno">B. </bdi>Issue summary</a></li><li class="tocline"><a class="tocxref" href="#references"><bdi class="secno">C. </bdi>References</a><ol class="toc"><li class="tocline"><a class="tocxref" href="#normative-references"><bdi class="secno">C.1 </bdi>Normative references</a></li></ol></li></ol></nav>
+</section><nav id="toc"><h2 class="introductory" id="table-of-contents">Table of Contents</h2><ol class="toc"><li class="tocline"><a class="tocxref" href="#current-status-of-document">Current Status of Document</a></li><li class="tocline"><a class="tocxref" href="#abstract">Abstract</a></li><li class="tocline"><a class="tocxref" href="#introduction"><bdi class="secno">1. </bdi>Introduction</a></li><li class="tocline"><a class="tocxref" href="#definitions"><bdi class="secno">2. </bdi>Definitions</a><ol class="toc"><li class="tocline"><a class="tocxref" href="#openapi-document"><bdi class="secno">2.1 </bdi>OpenAPI Document</a></li><li class="tocline"><a class="tocxref" href="#media-types"><bdi class="secno">2.2 </bdi>Media Types</a></li><li class="tocline"><a class="tocxref" href="#http-status-codes"><bdi class="secno">2.3 </bdi>HTTP Status Codes</a></li></ol></li><li class="tocline"><a class="tocxref" href="#conventions"><bdi class="secno">3. </bdi>Conventions</a><ol class="toc"><li class="tocline"><a class="tocxref" href="#oas-version"><bdi class="secno">3.1 </bdi>Versions</a></li><li class="tocline"><a class="tocxref" href="#format"><bdi class="secno">3.2 </bdi>Format</a></li><li class="tocline"><a class="tocxref" href="#data-types"><bdi class="secno">3.3 </bdi>Data Types</a><ol class="toc"><li class="tocline"><a class="tocxref" href="#working-with-binary-data"><bdi class="secno">3.3.1 </bdi>Working With Binary Data</a><ol class="toc"></ol></li></ol></li><li class="tocline"><a class="tocxref" href="#rich-text-formatting"><bdi class="secno">3.4 </bdi>Rich Text Formatting</a></li><li class="tocline"><a class="tocxref" href="#relative-references-in-uris"><bdi class="secno">3.5 </bdi>Relative References in URIs</a></li><li class="tocline"><a class="tocxref" href="#relative-references-in-urls"><bdi class="secno">3.6 </bdi>Relative References in URLs</a></li><li class="tocline"><a class="tocxref" href="#referencing-imports"><bdi class="secno">3.7 </bdi>Referencing Imports</a><ol class="toc"><li class="tocline"><a class="tocxref" href="#using-imported-names"><bdi class="secno">3.7.1 </bdi>Using Imported Names</a></li><li class="tocline"><a class="tocxref" href="#referencing-a-complete-document"><bdi class="secno">3.7.2 </bdi>Referencing a Complete Document</a></li><li class="tocline"><a class="tocxref" href="#locating-and-loading-imported-resources"><bdi class="secno">3.7.3 </bdi>Locating and Loading Imported Resources</a></li><li class="tocline"><a class="tocxref" href="#security-considerations-for-url-retrieval"><bdi class="secno">3.7.4 </bdi>Security Considerations for URL Retrieval</a></li></ol></li><li class="tocline"><a class="tocxref" href="#specification-extensions"><bdi class="secno">3.8 </bdi>Specification Extensions</a></li></ol></li><li class="tocline"><a class="tocxref" href="#document-processing"><bdi class="secno">4. </bdi>Document Processing</a><ol class="toc"><li class="tocline"><a class="tocxref" href="#parsing-documents"><bdi class="secno">4.1 </bdi>Parsing Documents</a></li><li class="tocline"><a class="tocxref" href="#structural-interoperability"><bdi class="secno">4.2 </bdi>Structural Interoperability</a></li><li class="tocline"><a class="tocxref" href="#resolving-implicit-connections"><bdi class="secno">4.3 </bdi>Resolving Implicit Connections</a></li><li class="tocline"><a class="tocxref" href="#undefined-and-implementation-defined-behavior"><bdi class="secno">4.4 </bdi>Undefined and Implementation-Defined Behavior</a></li></ol></li><li class="tocline"><a class="tocxref" href="#openapi-document-structure"><bdi class="secno">5. </bdi>OpenAPI Document Structure</a><ol class="toc"><li class="tocline"><a class="tocxref" href="#general-fixed-fields"><bdi class="secno">5.1 </bdi>General Fixed Fields</a></li><li class="tocline"><a class="tocxref" href="#info-object"><bdi class="secno">5.2 </bdi>Info Object</a><ol class="toc"><li class="tocline"><a class="tocxref" href="#info-object-fixed-fields"><bdi class="secno">5.2.1 </bdi>Fixed Fields</a></li><li class="tocline"><a class="tocxref" href="#info-object-example"><bdi class="secno">5.2.2 </bdi>Info Object Example</a></li></ol></li><li class="tocline"><a class="tocxref" href="#contact-object"><bdi class="secno">5.3 </bdi>Contact Object</a><ol class="toc"><li class="tocline"><a class="tocxref" href="#fixed-fields-0"><bdi class="secno">5.3.1 </bdi>Fixed Fields</a></li><li class="tocline"><a class="tocxref" href="#contact-object-example"><bdi class="secno">5.3.2 </bdi>Contact Object Example</a></li></ol></li><li class="tocline"><a class="tocxref" href="#license-object"><bdi class="secno">5.4 </bdi>License Object</a><ol class="toc"><li class="tocline"><a class="tocxref" href="#fixed-fields-1"><bdi class="secno">5.4.1 </bdi>Fixed Fields</a></li><li class="tocline"><a class="tocxref" href="#license-object-example"><bdi class="secno">5.4.2 </bdi>License Object Example</a></li></ol></li><li class="tocline"><a class="tocxref" href="#components-object"><bdi class="secno">5.5 </bdi>Components Object</a></li><li class="tocline"><a class="tocxref" href="#import-object"><bdi class="secno">5.6 </bdi>Import Object</a><ol class="toc"><li class="tocline"><a class="tocxref" href="#fixed-fields-2"><bdi class="secno">5.6.1 </bdi>Fixed Fields</a></li></ol></li><li class="tocline"><a class="tocxref" href="#api-shape"><bdi class="secno">5.7 </bdi>API Shape</a><ol class="toc"><li class="tocline"><a class="tocxref" href="#shape-fixed-fields"><bdi class="secno">5.7.1 </bdi>Shape Fixed Fields</a></li><li class="tocline"><a class="tocxref" href="#operation-object"><bdi class="secno">5.7.2 </bdi>Operation Object</a><ol class="toc"></ol></li></ol></li><li class="tocline"><a class="tocxref" href="#api-deployment"><bdi class="secno">5.8 </bdi>API Deployment</a><ol class="toc"><li class="tocline"><a class="tocxref" href="#deployment-fixed-fields"><bdi class="secno">5.8.1 </bdi>Deployment Fixed Fields</a></li><li class="tocline"><a class="tocxref" href="#deployment-example"><bdi class="secno">5.8.2 </bdi>Deployment Example</a></li><li class="tocline"><a class="tocxref" href="#deployment-object"><bdi class="secno">5.8.3 </bdi>Deployment Object</a><ol class="toc"></ol></li><li class="tocline"><a class="tocxref" href="#security-scheme-object"><bdi class="secno">5.8.4 </bdi>Security Scheme Object</a><ol class="toc"></ol></li><li class="tocline"><a class="tocxref" href="#credential-object"><bdi class="secno">5.8.5 </bdi>Credential Object</a><ol class="toc"></ol></li><li class="tocline"><a class="tocxref" href="#security-config-object"><bdi class="secno">5.8.6 </bdi>Security Config Object</a><ol class="toc"></ol></li></ol></li></ol></li><li class="tocline"><a class="tocxref" href="#appendix"><bdi class="secno">6. </bdi>Appendix</a></li><li class="tocline"><a class="tocxref" href="#revision-history"><bdi class="secno">A. </bdi>Revision History</a></li></ol></nav>
 
-<section id="conformance" class="introductory"><h1>Conformance</h1><p>As well as sections marked as non-normative, all authoring guidelines, diagrams, examples, and notes in this specification are non-normative. Everything else in this specification is normative.</p><p>
-        The key words <em class="rfc2119">MAY</em>, <em class="rfc2119">MUST</em>, <em class="rfc2119">MUST NOT</em>, <em class="rfc2119">NOT RECOMMENDED</em>, <em class="rfc2119">RECOMMENDED</em>, <em class="rfc2119">REQUIRED</em>, <em class="rfc2119">SHALL</em>, <em class="rfc2119">SHOULD</em>, and <em class="rfc2119">SHOULD NOT</em> in this document
-        are to be interpreted as described in
-        <a href="https://datatracker.ietf.org/doc/html/bcp14">BCP 14</a>
-        [<cite><a class="bibref" data-link-type="biblio" href="#bib-rfc2119" title="Key words for use in RFCs to Indicate Requirement Levels">RFC2119</a></cite>] [<cite><a class="bibref" data-link-type="biblio" href="#bib-rfc8174" title="Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words">RFC8174</a></cite>]
-        when, and only when, they appear in all capitals, as shown here.
-      </p>
+<section id="conformance" class="introductory"><h1>Conformance</h1><p>As well as sections marked as non-normative, all authoring guidelines, diagrams, examples, and notes in this specification are non-normative. Everything else in this specification is normative.</p>
 
 <p>This document is licensed under <a href="https://www.apache.org/licenses/LICENSE-2.0.html">The Apache License, Version 2.0</a>.</p>
 </section>
 
 
 <section id="introduction"><div class="header-wrapper"><h2 id="x1-introduction"><bdi class="secno">1. </bdi>Introduction</h2><a class="self-link" href="#introduction" aria-label="Permalink for Section 1."></a></div>
-<p>The OpenAPI Specification (OAS) defines a standard, language-agnostic interface to HTTP APIs which allows both humans and computers to discover and understand the capabilities of the service without access to source code, documentation, or through network traffic inspection. When properly defined, a consumer can understand and interact with the remote service with a minimal amount of implementation logic.</p>
-<p>An OpenAPI definition can then be used by documentation generation tools to display the API, code generation tools to generate servers and clients in various programming languages, testing tools, and many other use cases.</p>
 </section><section id="definitions"><div class="header-wrapper"><h2 id="x2-definitions"><bdi class="secno">2. </bdi>Definitions</h2><a class="self-link" href="#definitions" aria-label="Permalink for Section 2."></a></div>
 <section id="openapi-document"><div class="header-wrapper"><h3 id="x2-1-openapi-document"><bdi class="secno">2.1 </bdi>OpenAPI Document</h3><a class="self-link" href="#openapi-document" aria-label="Permalink for Section 2.1"></a></div>
-<p>An OpenAPI Description (OAD) formally describes the surface of an API and its semantics. It is composed of an <a href="#documentStructure" class="respec-offending-element" title="Broken local reference found in document." id="respec-offender-broken-local-reference-found-in-document">entry document</a> and any/all of its referenced documents. </p>
-<div class="note" id="issue-container-generatedID"><div role="heading" class="ednote-title marker" id="h-ednote" aria-level="2"><span>Editor's note</span></div><p class="">Need to define what are the required top level properties</p></div>
-
 </section><section id="media-types"><div class="header-wrapper"><h3 id="x2-2-media-types"><bdi class="secno">2.2 </bdi>Media Types</h3><a class="self-link" href="#media-types" aria-label="Permalink for Section 2.2"></a></div>
-<p>Media type definitions are spread across several resources.
-The media type definitions <em class="rfc2119">SHOULD</em> be in compliance with <a href="https://tools.ietf.org/html/rfc6838">RFC6838</a>.</p>
-<p>Some examples of possible media type definitions:</p>
-<pre><code class="shell hljs" aria-busy="false">  text/plain; charset=utf-8
-  application/json
-  application/vnd.github+json
-  application/vnd.github.v3+json
-  application/vnd.github.v3.raw+json
-  application/vnd.github.v3.text+json
-  application/vnd.github.v3.html+json
-  application/vnd.github.v3.full+json
-  application/vnd.github.v3.diff
-  application/vnd.github.v3.patch
-</code></pre>
 </section><section id="http-status-codes"><div class="header-wrapper"><h3 id="x2-3-http-status-codes"><bdi class="secno">2.3 </bdi>HTTP Status Codes</h3><a class="self-link" href="#http-status-codes" aria-label="Permalink for Section 2.3"></a></div>
-<p>The HTTP Status Codes are used to indicate the status of the executed operation. 
-Status codes <em class="rfc2119">SHOULD</em> be selected from the available status codes registered in the <a href="https://www.iana.org/assignments/http-status-codes/http-status-codes.xhtml">IANA Status Code Registry</a>.</p>
 </section></section><section id="conventions"><div class="header-wrapper"><h2 id="x3-conventions"><bdi class="secno">3. </bdi>Conventions</h2><a class="self-link" href="#conventions" aria-label="Permalink for Section 3."></a></div>
-<section id="versions"><div class="header-wrapper"><h3 id="oas-version"><bdi class="secno">3.1 </bdi>Versions</h3><a class="self-link" href="#oas-version" aria-label="Permalink for Section 3.1"></a></div><p>The OpenAPI Specification is versioned using a <code>major</code>.<code>minor</code>.<code>patch</code> versioning scheme. The <code>major</code>.<code>minor</code> portion of the version string (for example <code>3.1</code>) <em class="rfc2119">SHALL</em> designate the OAS feature set. <em><code>.patch</code></em> versions address errors in, or provide clarifications to, this document, not the feature set. Tooling which supports OAS 3.1 <em class="rfc2119">SHOULD</em> be compatible with all OAS 3.1.* versions. The patch version <em class="rfc2119">SHOULD NOT</em> be considered by tooling, making no distinction between <code>3.1.0</code> and <code>3.1.1</code> for example.</p>
-<p>Occasionally, non-backwards compatible changes may be made in <code>minor</code> versions of the OAS where impact is believed to be low relative to the benefit provided.</p>
-<p>An OpenAPI document compatible with OAS 3.*.* contains a required <a href="#oasVersion" class="respec-offending-element" title="Broken local reference found in document." id="respec-offender-broken-local-reference-found-in-document-0"><code>openapi</code></a> field which designates the version of the OAS that it uses.</p>
-</section><section id="format"><div class="header-wrapper"><h3 id="x3-2-format"><bdi class="secno">3.2 </bdi>Format</h3><a class="self-link" href="#format" aria-label="Permalink for Section 3.2"></a></div>
-<p>An OpenAPI document that conforms to the OpenAPI Specification is itself a JSON object, which may be represented either in JSON or YAML format.</p>
-<p>For example, if a field has an array value, the JSON array representation will be used:</p>
-<pre><code class="json hljs" aria-busy="false">{
-   <span class="hljs-attr">"field"</span>: [ <span class="hljs-number">1</span>, <span class="hljs-number">2</span>, <span class="hljs-number">3</span> ]
-}
-</code></pre>
-<p>All field names in the specification are <strong>case sensitive</strong>.
-This includes all fields that are used as keys in a map, except where explicitly noted that keys are <strong>case insensitive</strong>.</p>
-<p>The schema exposes two types of fields: Fixed fields, which have a declared name, and Patterned fields, which declare a regex pattern for the field name.</p>
-<p>Patterned fields <em class="rfc2119">MUST</em> have unique names within the containing object. </p>
-<p>In order to preserve the ability to round-trip between YAML and JSON formats, YAML version <a href="https://yaml.org/spec/1.2/spec.html">1.2</a> is <em class="rfc2119">RECOMMENDED</em> along with some additional constraints:</p>
-<ul>
-<li>Tags <em class="rfc2119">MUST</em> be limited to those allowed by the <a href="https://yaml.org/spec/1.2/spec.html#id2803231">JSON Schema ruleset</a>.</li>
-<li>Keys used in YAML maps <em class="rfc2119">MUST</em> be limited to a scalar string, as defined by the <a href="https://yaml.org/spec/1.2/spec.html#id2802346">YAML Failsafe schema ruleset</a>.</li>
-</ul>
-<p><strong>Note:</strong> While APIs may be defined by OpenAPI documents in either YAML or JSON format, the API request and response bodies and other content are not required to be JSON or YAML.</p>
+<section id="versions"><div class="header-wrapper"><h3 id="oas-version"><bdi class="secno">3.1 </bdi>Versions</h3><a class="self-link" href="#oas-version" aria-label="Permalink for Section 3.1"></a></div></section><section id="format"><div class="header-wrapper"><h3 id="x3-2-format"><bdi class="secno">3.2 </bdi>Format</h3><a class="self-link" href="#format" aria-label="Permalink for Section 3.2"></a></div>
 </section><section id="data-types"><div class="header-wrapper"><h3 id="x3-3-data-types"><bdi class="secno">3.3 </bdi>Data Types</h3><a class="self-link" href="#data-types" aria-label="Permalink for Section 3.3"></a></div>
-<div class="issue" id="issue-container-number-131"><div role="heading" class="issue-title marker" id="h-issue" aria-level="2"><a href="https://github.com/OAI/sig-moonwalk/issues/131"><span class="issue-number">Issue 131</span></a><span class="issue-label">: Can the Data Types section be replaced by a reference to the format registry?</span></div><p class="">Replace this paragraph with a reference to the format registry</p></div>
-
 <section id="working-with-binary-data"><div class="header-wrapper"><h4 id="x3-3-1-working-with-binary-data"><bdi class="secno">3.3.1 </bdi>Working With Binary Data</h4><a class="self-link" href="#working-with-binary-data" aria-label="Permalink for Section 3.3.1"></a></div>
-<p>The OAS can describe either <em>raw</em> or <em>encoded</em> binary data.</p>
-<ul>
-<li><strong>raw binary</strong> is used where unencoded binary data is allowed, such as when sending a binary payload as the entire HTTP message body, or as part of a <code>multipart/*</code> payload that allows binary parts</li>
-<li><strong>encoded binary</strong> is used where binary data is embedded in a text-only format such as <code>application/json</code> or <code>application/x-www-form-urlencoded</code> (either as a message body or in the URL query string).</li>
-</ul>
-<p>In the following table showing how to use Schema Object keywords for binary data, we use <code>image/png</code> as an example binary media type.  Any binary media type, including <code>application/octet-stream</code>, is sufficient to indicate binary content.</p>
-<table>
-<thead>
-<tr>
-<th>Keyword</th>
-<th>Raw</th>
-<th>Encoded</th>
-<th>Comments</th>
-</tr>
-</thead>
-<tbody><tr>
-<td><code>type</code></td>
-<td><em>omit</em></td>
-<td><code>string</code></td>
-<td>raw binary is <a href="https://datatracker.ietf.org/doc/html/draft-bhutton-json-schema-00#section-4.2.3">outside of <code>type</code></a></td>
-</tr>
-<tr>
-<td><code>contentMediaType</code></td>
-<td><code>image/png</code></td>
-<td><code>image/png</code></td>
-<td>can sometimes be omitted if redundant (see below)</td>
-</tr>
-<tr>
-<td><code>contentEncoding</code></td>
-<td><em>omit</em></td>
-<td><code>base64</code>&nbsp;or&nbsp;<code>base64url</code></td>
-<td>other encodings are <a href="https://datatracker.ietf.org/doc/html/draft-bhutton-json-schema-validation-00#section-8.3">allowed</a></td>
-</tr>
-</tbody></table>
-<p>Note that the encoding indicated by <code>contentEncoding</code>, which inflates the size of data in order to represent it as 7-bit ASCII text, is unrelated to HTTP's <code>Content-Encoding</code> header, which indicates whether and how a message body has been compressed and is applied after all content serialization described in this section has occurred.  Since HTTP allows unencoded binary message bodies, there is no standardized HTTP header for indicating base64 or similar encoding of an entire message body.</p>
-<p>Using a <code>contentEncoding</code> of <code>base64url</code> ensures that URL encoding (as required in the query string and in message bodies of type <code>application/x-www-form-urlencoded</code>) does not need to further encode any part of the already-encoded binary data.</p>
-<p>The <code>contentMediaType</code> keyword is redundant if the media type is already set:</p>
-<ul>
-<li>as the key for a <a href="#mediaTypeObject" class="respec-offending-element" title="Broken local reference found in document." id="respec-offender-broken-local-reference-found-in-document-1"><code>MediaType Object</code></a></li>
-<li>in the <code>contentType</code> field of an <a href="#encodingObject" class="respec-offending-element" title="Broken local reference found in document." id="respec-offender-broken-local-reference-found-in-document-2"><code>Encoding Object</code></a></li>
-</ul>
-<p>If the Schema Object will be processed by a non-OAS-aware JSON Schema implementation, it may be useful to include <code>contentMediaType</code> even if it is redundant.  However, if <code>contentMediaType</code> contradicts a relevant Media Type Object or Encoding Object, then <code>contentMediaType</code> <em class="rfc2119">SHALL</em> be ignored.</p>
-<p>The <code>maxLength</code> keyword <em class="rfc2119">MAY</em> be used to set an expected upper bound on the length of a streaming payload.  The keyword can be applied to either string data, including encoded binary data, or to unencoded binary data.  For unencoded binary, the length is the number of octets.</p>
 <section id="migrating-binary-descriptions-from-oas-3-0"><div class="header-wrapper"><h5 id="x3-3-1-1-migrating-binary-descriptions-from-oas-3-0"><bdi class="secno">3.3.1.1 </bdi>Migrating binary descriptions from OAS 3.0</h5><a class="self-link" href="#migrating-binary-descriptions-from-oas-3-0" aria-label="Permalink for Section 3.3.1.1"></a></div>
-<p>The following table shows how to migrate from OAS 3.0 binary data descriptions, continuing to use <code>image/png</code> as the example binary media type:</p>
-<table>
-<thead>
-<tr>
-<th>OAS &lt; 3.1</th>
-<th>OAS 3.1</th>
-<th>Comments</th>
-</tr>
-</thead>
-<tbody><tr>
-<td><code>type: string</code><br><code>format: binary</code></td>
-<td><code>contentMediaType: image/png</code></td>
-<td>if redundant, can be omitted, often resulting in an empty Schema Object</td>
-</tr>
-<tr>
-<td><code>type: string</code><br><code>format: byte</code></td>
-<td><code>type: string</code><br><code>contentMediaType: image/png</code><br><code>contentEncoding: base64</code></td>
-<td>note that <code>base64url</code> can be used to avoid re-encoding the base64 string to be URL-safe</td>
-</tr>
-</tbody></table>
 </section></section></section><section id="rich-text-formatting"><div class="header-wrapper"><h3 id="x3-4-rich-text-formatting"><bdi class="secno">3.4 </bdi>Rich Text Formatting</h3><a class="self-link" href="#rich-text-formatting" aria-label="Permalink for Section 3.4"></a></div>
-<p>Throughout the specification <code>description</code> fields are noted as supporting CommonMark markdown formatting.
-Where OpenAPI tooling renders rich text it <em class="rfc2119">MUST</em> support, at a minimum, markdown syntax as described by <a href="https://spec.commonmark.org/0.27/">CommonMark 0.27</a>. Tooling <em class="rfc2119">MAY</em> choose to ignore some CommonMark features to address security concerns. </p>
 </section><section id="relative-references-in-uris"><div class="header-wrapper"><h3 id="x3-5-relative-references-in-uris"><bdi class="secno">3.5 </bdi>Relative References in URIs</h3><a class="self-link" href="#relative-references-in-uris" aria-label="Permalink for Section 3.5"></a></div>
-<p>Unless specified otherwise, all properties that are URIs <em class="rfc2119">MAY</em> be relative references as defined by <a href="https://tools.ietf.org/html/rfc3986#section-4.2">RFC3986</a>.</p>
-<p>Relative references, including those in <a href="#referenceObject" class="respec-offending-element" title="Broken local reference found in document." id="respec-offender-broken-local-reference-found-in-document-3"><code>Reference Objects</code></a>, <a href="#pathItemObject" class="respec-offending-element" title="Broken local reference found in document." id="respec-offender-broken-local-reference-found-in-document-4"><code>PathItem Object</code></a> <code>$ref</code> fields, <a href="#linkObject" class="respec-offending-element" title="Broken local reference found in document." id="respec-offender-broken-local-reference-found-in-document-5"><code>Link Object</code></a> <code>operationRef</code> fields and <a href="#exampleObject" class="respec-offending-element" title="Broken local reference found in document." id="respec-offender-broken-local-reference-found-in-document-6"><code>Example Object</code></a> <code>externalValue</code> fields, are resolved using the referring document as the Base URI according to <a href="https://tools.ietf.org/html/rfc3986#section-5.2">RFC3986</a>.</p>
-<p>If a URI contains a fragment identifier, then the fragment should be resolved per the fragment resolution mechanism of the referenced document.  If the representation of the referenced document is JSON or YAML, then the fragment identifier <em class="rfc2119">SHOULD</em> be interpreted as a JSON-Pointer as per <a href="https://tools.ietf.org/html/rfc6901">RFC6901</a>.</p>
-<p>Relative references in <a href="#schemaObject" class="respec-offending-element" title="Broken local reference found in document." id="respec-offender-broken-local-reference-found-in-document-7"><code>Schema Objects</code></a>, including any that appear as <code>$id</code> values, use the nearest parent <code>$id</code> as a Base URI, as described by <a href="https://tools.ietf.org/html/draft-bhutton-json-schema-00#section-8.2">JSON Schema Specification Draft 2020-12</a>.  If no parent schema contains an <code>$id</code>, then the Base URI <em class="rfc2119">MUST</em> be determined according to <a href="https://tools.ietf.org/html/rfc3986#section-5.1">RFC3986</a>.</p>
 </section><section id="relative-references-in-urls"><div class="header-wrapper"><h3 id="x3-6-relative-references-in-urls"><bdi class="secno">3.6 </bdi>Relative References in URLs</h3><a class="self-link" href="#relative-references-in-urls" aria-label="Permalink for Section 3.6"></a></div>
-<p>Unless specified otherwise, all properties that are URLs <em class="rfc2119">MAY</em> be relative references as defined by <a href="https://tools.ietf.org/html/rfc3986#section-4.2">RFC3986</a>.
-Unless specified otherwise, relative references are resolved using the URLs defined in the <a href="#serverObject" class="respec-offending-element" title="Broken local reference found in document." id="respec-offender-broken-local-reference-found-in-document-8"><code>Server Object</code></a> as a Base URL. Note that these themselves <em class="rfc2119">MAY</em> be relative to the referring document.</p>
 </section><section id="referencing-imports"><div class="header-wrapper"><h3 id="x3-7-referencing-imports"><bdi class="secno">3.7 </bdi>Referencing Imports</h3><a class="self-link" href="#referencing-imports" aria-label="Permalink for Section 3.7"></a></div>
 <section id="using-imported-names"><div class="header-wrapper"><h4 id="x3-7-1-using-imported-names"><bdi class="secno">3.7.1 </bdi>Using Imported Names</h4><a class="self-link" href="#using-imported-names" aria-label="Permalink for Section 3.7.1"></a></div>
-<div class="note" id="issue-container-generatedID-0"><div role="heading" class="ednote-title marker" id="h-ednote-0" aria-level="2"><span>Editor's note</span></div><p class="">This syntax comes directly from the deployments examples.  It does involve values that are either objects (inline) or strings (imported names) which might be of concern to developers in strictly typed languages.
-</p></div>
-
-<p>Imported names are used in specific contexts that require a particular type of Object.  The syntax for using a name is:</p>
-<pre><code class="YAML hljs" aria-busy="false">  &lt;fieldname&gt;: &lt;namespace&gt;:&lt;componentname&gt;
-</code></pre>
-<p>where <code>&lt;namespace&gt;</code> is replaced by the namespace from an Import Object in the current document, and <code>&lt;componentname&gt;</code> <em class="rfc2119">MUST</em> but the name of an Object in the imported document's Components Object, under the appropriate semantic type section.  Therefore:</p>
-<pre><code class="YAML hljs" aria-busy="false">openapi: 4.0.0
-self: https://example.com/fooComponents
-components:
-  pathItems:
-    Foos: {...}
-  schemas:
-    Foos: {...}
-</code></pre>
-<pre><code class="YAML hljs" aria-busy="false">openapi: 4.0.0
-self: https://example.com/fooPaths
-components:
-  pathItems:
-    Bars: {...}
-imports:
-- namespace: foo
-  href: fooComponents
-paths:
-  /foos: foo:Foos
-  /bars: self:Bars
-</code></pre>
-<p>In this example, the import <code>href</code> "fooComponents" is an IRI-reference resolved against <code>self</code> as a base IRI, producing <code>https://example.com/fooComponents</code>.  Since the <code>foo:Foos</code> is found where a Path Item Object is expected, the "Foos" entry under <code>pathItems</code> is used rather than the identically-named Schema Object under <code>schemas</code>.</p>
-<p>The <code>/bars</code> entry shows how to use a component from the current document with the reserved <code>self</code> namespace.</p>
 </section><section id="referencing-a-complete-document"><div class="header-wrapper"><h4 id="x3-7-2-referencing-a-complete-document"><bdi class="secno">3.7.2 </bdi>Referencing a Complete Document</h4><a class="self-link" href="#referencing-a-complete-document" aria-label="Permalink for Section 3.7.2"></a></div>
-<p>Some fields require a document-level reference, such as connecting a deployment to its shape.  In that case, only the namespace is used, without the component name separator:</p>
-<pre><code class="YAML hljs" aria-busy="false">  &lt;fieldname&gt;: &lt;namespace&gt;
-</code></pre>
-<p>This form <em class="rfc2119">MUST</em> only be used when it makes sense to talk about the effect of the complete document, rather than components within the document.</p>
 </section><section id="locating-and-loading-imported-resources"><div class="header-wrapper"><h4 id="x3-7-3-locating-and-loading-imported-resources"><bdi class="secno">3.7.3 </bdi>Locating and Loading Imported Resources</h4><a class="self-link" href="#locating-and-loading-imported-resources" aria-label="Permalink for Section 3.7.3"></a></div>
-<div class="note" id="issue-container-generatedID-1"><div role="heading" class="ednote-title marker" id="h-ednote-1" aria-level="2"><span>Editor's note</span></div><p class="">The requirements in this section are phrased to allow, but not require, compliant implementations to delegate all I/O to applications.  It should also be possible to implement resolvers separate from the core OAS support, somewhat like reference resolvers/removers but with much better UX.
-</p></div>
-
-<p>Implementations <em class="rfc2119">MUST</em> support two methods of resolving imports:</p>
-<ul>
-<li>matching the import IRI to the resource's self-assigned IRI</li>
-<li>treating the import IRI as a retrieval URL</li>
-</ul>
-<p>Note that interacting with local files is equivalent to retrieval using <code>file:</code> IRIs ([RFC 8089])(<a href="https://datatracker.ietf.org/doc/html/rfc8089">https://datatracker.ietf.org/doc/html/rfc8089</a>).</p>
-<p>As implementations cannot determine a self-assigned IRI without parsing the resource, they <em class="rfc2119">MUST</em> support pre-loading resources or otherwise configuring some mechanism to load likely candidates on demand.</p>
-<p>Implementations <em class="rfc2119">MAY</em> directly support URL retrieval.  Those that do <em class="rfc2119">SHOULD</em> support URI schemes most relevant to their environment, such as <code>file:</code> for local access and <code>https:</code> for network access.</p>
-<p>Implementations that do not support URL retrieval <em class="rfc2119">MUST</em> support associating a retrieval URL with each resource.</p>
 </section><section id="security-considerations-for-url-retrieval"><div class="header-wrapper"><h4 id="x3-7-4-security-considerations-for-url-retrieval"><bdi class="secno">3.7.4 </bdi>Security Considerations for URL Retrieval</h4><a class="self-link" href="#security-considerations-for-url-retrieval" aria-label="Permalink for Section 3.7.4"></a></div>
-<div class="note" id="issue-container-generatedID-2"><div role="heading" class="ednote-title marker" id="h-ednote-2" aria-level="2"><span>Editor's note</span></div><p class="">TODO</p></div>
-
-
 </section></section><section id="specification-extensions"><div class="header-wrapper"><h3 id="x3-8-specification-extensions"><bdi class="secno">3.8 </bdi>Specification Extensions</h3><a class="self-link" href="#specification-extensions" aria-label="Permalink for Section 3.8"></a></div>
-<p>While the OpenAPI Specification tries to accommodate most use cases, additional data can be added to extend the specification at certain points.</p>
-<p>The extensions properties are implemented as patterned fields that are always prefixed by <code>"x-"</code>.</p>
-<table>
-<thead>
-<tr>
-<th>Field Pattern</th>
-<th align="center">Type</th>
-<th>Description</th>
-</tr>
-</thead>
-<tbody><tr>
-<td>^x-</td>
-<td align="center">Any</td>
-<td>Allows extensions to the OpenAPI Schema. The field name <em class="rfc2119">MUST</em> begin with <code>x-</code>, for example, <code>x-internal-id</code>. Field names beginning <code>x-oai-</code> and <code>x-oas-</code> are reserved for uses defined by the <a href="https://www.openapis.org/">OpenAPI Initiative</a>. The value can be <code>null</code>, a primitive, an array or an object.</td>
-</tr>
-</tbody></table>
-<p>The extensions may or may not be supported by the available tooling, but those may be extended as well to add requested support (if tools are internal or open-sourced).</p>
 </section></section><section id="document-processing"><div class="header-wrapper"><h2 id="x4-document-processing"><bdi class="secno">4. </bdi>Document Processing</h2><a class="self-link" href="#document-processing" aria-label="Permalink for Section 4."></a></div>
 <section id="parsing-documents"><div class="header-wrapper"><h3 id="x4-1-parsing-documents"><bdi class="secno">4.1 </bdi>Parsing Documents</h3><a class="self-link" href="#parsing-documents" aria-label="Permalink for Section 4.1"></a></div>
-<p>In order to properly handle <a href="#schemaObject" class="respec-offending-element" title="Broken local reference found in document." id="respec-offender-broken-local-reference-found-in-document-9">Schema Objects</a>, OAS 3.1 inherits the parsing requirements of <a href="https://datatracker.ietf.org/doc/html/draft-bhutton-json-schema-00#section-9">JSON Schema draft 2020-12 §9</a>, with appropriate modifications regarding base URIs as specified in <a href="#relativeReferencesURI" class="respec-offending-element" title="Broken local reference found in document." id="respec-offender-broken-local-reference-found-in-document-10">Relative References In URIs</a>.</p>
-<p>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.</p>
-<p>Implementations <em class="rfc2119">MAY</em> support complete-document parsing in any of the following ways:</p>
-<ul>
-<li>Detecting OpenAPI or JSON Schema documents using media types</li>
-<li>Detecting OpenAPI documents through the root <code>openapi</code> property</li>
-<li>Detecting JSON Schema documents through detecting keywords or otherwise successfully parsing the document in accordance with the JSON Schema specification</li>
-<li>Detecting a document containing a referenceable Object at its root based on the expected type of the reference</li>
-<li>Allowing users to configure the type of documents that might be loaded due to a reference to a non-root Object</li>
-</ul>
-<p>Implementations that parse referenced fragments of OpenAPI content without regard for the content of the rest of the containing document will miss keywords that change the meaning and behavior of the reference target.
-In particular, failing to take into account keywords that change the base URI introduces security risks by causing references to resolve to unintended URIs, with unpredictable results.
-While some implementations support this sort of parsing due to the requirements of past versions of this specification, in version 3.1, the result of parsing fragments in isolation is <em>undefined</em> and likely to contradict the requirements of this specification.</p>
-<p>While it is possible to structure certain OpenAPI Descriptions to ensure that they will behave correctly when references are parsed as isolated fragments, depending on this is <em class="rfc2119">NOT RECOMMENDED</em>.
-This specification does not explicitly enumerate the conditions under which such behavior is safe, and provides no guarantee for continued safety in any future versions of the OAS.</p>
-<p>A special case of parsing fragments of OAS content would be if such fragments are embedded in another format, referred to as an <em>embedding format</em> with respect to the OAS.
-Note that the OAS itself is an embedding format with respect to JSON Schema, which is embedded as Schema Objects.
-It is the responsibility of an embedding format to define how to parse embedded content, and OAS implementations that do not document support for an embedding format cannot be expected to parse embedded OAS content correctly.</p>
 </section><section id="structural-interoperability"><div class="header-wrapper"><h3 id="x4-2-structural-interoperability"><bdi class="secno">4.2 </bdi>Structural Interoperability</h3><a class="self-link" href="#structural-interoperability" aria-label="Permalink for Section 4.2"></a></div>
-<p>When parsing an OAD, JSON or YAML objects are parsed into specific Objects (such as <a href="#operationObject" class="respec-offending-element" title="Broken local reference found in document." id="respec-offender-broken-local-reference-found-in-document-11">Operation Objects</a>, <a href="#responseObject" class="respec-offending-element" title="Broken local reference found in document." id="respec-offender-broken-local-reference-found-in-document-12">Response Objects</a>, <a href="#referenceObject" class="respec-offending-element" title="Broken local reference found in document." id="respec-offender-broken-local-reference-found-in-document-13">Reference Objects</a>, 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:</p>
-<ul>
-<li>As a full OpenAPI Description document (an <a href="#oasObject" class="respec-offending-element" title="Broken local reference found in document." id="respec-offender-broken-local-reference-found-in-document-14">OpenAPI Object</a> taking up an entire document)</li>
-<li>As the Object type implied by its parent Object within the document</li>
-<li>As a reference target, with the Object type matching the reference source's context</li>
-</ul>
-<p>If the same JSON/YAML object is parsed multiple times and the respective contexts require it to be parsed as <em>different</em> Object types, the resulting behavior is <em>implementation defined</em>, and <em class="rfc2119">MAY</em> be treated as an error if detected.  An example would be referencing an empty Schema Object under <code>#/components/schemas</code> where a Path Item Object is expected, as an empty object is valid for both types.  For maximum interoperability, it is <em class="rfc2119">RECOMMENDED</em> that OpenAPI Description authors avoid such scenarios.</p>
 </section><section id="resolving-implicit-connections"><div class="header-wrapper"><h3 id="x4-3-resolving-implicit-connections"><bdi class="secno">4.3 </bdi>Resolving Implicit Connections</h3><a class="self-link" href="#resolving-implicit-connections" aria-label="Permalink for Section 4.3"></a></div>
 </section><section id="undefined-and-implementation-defined-behavior"><div class="header-wrapper"><h3 id="x4-4-undefined-and-implementation-defined-behavior"><bdi class="secno">4.4 </bdi>Undefined and Implementation-Defined Behavior</h3><a class="self-link" href="#undefined-and-implementation-defined-behavior" aria-label="Permalink for Section 4.4"></a></div>
-<p>This specification deems certain situations to have either <em>undefined</em> or <em>implementation-defined</em> behavior.</p>
-<p>Behavior described as <em>undefined</em> is likely, at least in some circumstances, to result in outcomes that contradict the specification.
-This description is used when detecting the contradiction is impossible or impractical.
-Implementations <em class="rfc2119">MAY</em> support undefined scenarios for historical reasons, including ambiguous text in prior versions of the specification.
-This support might produce correct outcomes in many cases, but relying on it is <em class="rfc2119">NOT RECOMMENDED</em> as there is no guarantee that it will work across all tools or with future specification versions, even if those versions are otherwise strictly compatible with this one.</p>
-<p>Behavior described as <em>implementation-defined</em> allows implementations to choose which of several different-but-compliant approaches to a requirement to implement.
-This documents ambiguous requirements that API description authors are <em class="rfc2119">RECOMMENDED</em> to avoid in order to maximize interoperability.
-Unlike undefined behavior, it is safe to rely on implementation-defined behavior if <em>and only if</em> it can be guaranteed that all relevant tools support the same behavior.</p>
 </section></section><section id="openapi-document-structure"><div class="header-wrapper"><h2 id="x5-openapi-document-structure"><bdi class="secno">5. </bdi>OpenAPI Document Structure</h2><a class="self-link" href="#openapi-document-structure" aria-label="Permalink for Section 5."></a></div>
-<p>The features of an OpenAPI description can be divided into two main categories: API shape and API deployment. The shape of an API can be described independently of deployment.  An API shape could be deployed many times, but a deployment must reference a single API shape.</p>
-<p>The fields that represent the API shape and API deployment both live at the root of an OpenAPI document.</p>
 <section id="general-fixed-fields"><div class="header-wrapper"><h3 id="x5-1-general-fixed-fields"><bdi class="secno">5.1 </bdi>General Fixed Fields</h3><a class="self-link" href="#general-fixed-fields" aria-label="Permalink for Section 5.1"></a></div>
-<table>
-<thead>
-<tr>
-<th>Field Name</th>
-<th align="center">Type</th>
-<th>Description</th>
-</tr>
-</thead>
-<tbody><tr>
-<td>openapi</td>
-<td align="center"><code>string</code></td>
-<td><strong><em class="rfc2119">REQUIRED</em></strong>. This string <em class="rfc2119">MUST</em> be the <a href="#versions">version number</a> of the OpenAPI Specification that the OpenAPI document uses. The <code>openapi</code> field <em class="rfc2119">SHOULD</em> be used by tooling to interpret the OpenAPI document. This is <em>not</em> related to the API <a href="#infoVersion" class="respec-offending-element" title="Broken local reference found in document." id="respec-offender-broken-local-reference-found-in-document-15"><code>info.version</code></a> string.</td>
-</tr>
-<tr>
-<td>self</td>
-<td align="center"><code>IRI-reference</code> (without a fragment)</td>
-<td>Sets the IRI of this document, which also serves as its base IRI in accordance with <a href="https://www.rfc-editor.org/rfc/rfc3986#section-5.1.1">RFC 3986 §5.1.1</a>; the value <em class="rfc2119">MUST NOT</em> be the empty string</td>
-</tr>
-<tr>
-<td>info</td>
-<td align="center"><a href="#info-object">Info Object</a></td>
-<td><strong><em class="rfc2119">REQUIRED</em></strong>. Provides metadata about the API. The metadata <em class="rfc2119">MAY</em> be used by tooling as required.</td>
-</tr>
-<tr>
-<td>jsonSchemaDialect</td>
-<td align="center"><code>string</code></td>
-<td>The default value for the <code>$schema</code> keyword within <a href="#schema-object" class="respec-offending-element" title="Broken local reference found in document." id="respec-offender-broken-local-reference-found-in-document-16">Schema Objects</a> contained within this OAS document. This <em class="rfc2119">MUST</em> be in the form of a URI.</td>
-</tr>
-<tr>
-<td>imports</td>
-<td align="center">[ <a href="#import-object">Import Object</a> ]</td>
-<td>A list of resources to import, from which all references within this document <em class="rfc2119">MUST</em> be resolved.</td>
-</tr>
-<tr>
-<td>components</td>
-<td align="center"><a href="#components-object">Components Object</a></td>
-<td>An element to hold various schemas for the document.</td>
-</tr>
-<tr>
-<td>tags</td>
-<td align="center">[ <a href="#tag-object" class="respec-offending-element" title="Broken local reference found in document." id="respec-offender-broken-local-reference-found-in-document-17">Tag Object</a> ]</td>
-<td>A list of tags used by the document with additional metadata. The order of the tags can be used to reflect on their order by the parsing tools. Not all tags that are used by the <a href="#operation-object">Operation Object</a> must be declared. The tags that are not declared <em class="rfc2119">MAY</em> be organized randomly or based on the tools' logic. Each tag name in the list <em class="rfc2119">MUST</em> be unique.</td>
-</tr>
-</tbody></table>
-<p>The value of <code>self</code> is an <em>identifier</em>, and not necessarily a <em>locator</em>.  The value need not be usable as a URL, and even if it is, the document need not be accessible at that location.</p>
-<p>This object <em class="rfc2119">MAY</em> be extended with <a href="#specification-extensions">Specification Extensions</a>.</p>
 </section><section id="info-object"><div class="header-wrapper"><h3 id="x5-2-info-object"><bdi class="secno">5.2 </bdi>Info Object</h3><a class="self-link" href="#info-object" aria-label="Permalink for Section 5.2"></a></div>
-<p>The object provides metadata about the API.
-The metadata <em class="rfc2119">MAY</em> be used by the clients if needed, and <em class="rfc2119">MAY</em> be presented in editing or documentation generation tools for convenience.</p>
-<section id="fixed-fields"><div class="header-wrapper"><h4 id="info-object-fixed-fields"><bdi class="secno">5.2.1 </bdi>Fixed Fields</h4><a class="self-link" href="#info-object-fixed-fields" aria-label="Permalink for Section 5.2.1"></a></div><table>
-<thead>
-<tr>
-<th>Field Name</th>
-<th align="center">Type</th>
-<th>Description</th>
-</tr>
-</thead>
-<tbody><tr>
-<td>title</td>
-<td align="center"><code>string</code></td>
-<td><strong><em class="rfc2119">REQUIRED</em></strong>. The title of the API.</td>
-</tr>
-<tr>
-<td>summary</td>
-<td align="center"><code>string</code></td>
-<td>A short summary of the API.</td>
-</tr>
-<tr>
-<td>description</td>
-<td align="center"><code>string</code></td>
-<td>A description of the API. <a href="https://spec.commonmark.org/">CommonMark syntax</a> <em class="rfc2119">MAY</em> be used for rich text representation.</td>
-</tr>
-<tr>
-<td>termsOfService</td>
-<td align="center"><code>string</code></td>
-<td>A URL to the Terms of Service for the API. This <em class="rfc2119">MUST</em> be in the form of a URL.</td>
-</tr>
-<tr>
-<td>contact</td>
-<td align="center"><a href="#contact-object">Contact Object</a></td>
-<td>The contact information for the exposed API.</td>
-</tr>
-<tr>
-<td>license</td>
-<td align="center"><a href="#license-object">License Object</a></td>
-<td>The license information for the exposed API.</td>
-</tr>
-<tr>
-<td>version</td>
-<td align="center"><code>string</code></td>
-<td><strong><em class="rfc2119">REQUIRED</em></strong>. The version of the OpenAPI description (which is distinct from the <a href="#oas-version">OpenAPI Specification version</a> or the API implementation version).</td>
-</tr>
-<tr>
-<td>externalDocs</td>
-<td align="center"><a href="#externalDocumentationObject" class="respec-offending-element" title="Broken local reference found in document." id="respec-offender-broken-local-reference-found-in-document-18">External Documentation Object</a></td>
-<td>Additional external documentation.</td>
-</tr>
-</tbody></table>
-<p>This object <em class="rfc2119">MAY</em> be extended with <a href="#specification-extensions">Specification Extensions</a>.</p>
-</section><section id="info-object-example"><div class="header-wrapper"><h4 id="x5-2-2-info-object-example"><bdi class="secno">5.2.2 </bdi>Info Object Example</h4><a class="self-link" href="#info-object-example" aria-label="Permalink for Section 5.2.2"></a></div>
-<pre><code class="json hljs" aria-busy="false">{
-  <span class="hljs-attr">"title"</span>: <span class="hljs-string">"Sample Pet Store App"</span>,
-  <span class="hljs-attr">"summary"</span>: <span class="hljs-string">"A pet store manager."</span>,
-  <span class="hljs-attr">"description"</span>: <span class="hljs-string">"This is a sample server for a pet store."</span>,
-  <span class="hljs-attr">"termsOfService"</span>: <span class="hljs-string">"https://example.com/terms/"</span>,
-  <span class="hljs-attr">"contact"</span>: {
-    <span class="hljs-attr">"name"</span>: <span class="hljs-string">"API Support"</span>,
-    <span class="hljs-attr">"url"</span>: <span class="hljs-string">"https://www.example.com/support"</span>,
-    <span class="hljs-attr">"email"</span>: <span class="hljs-string">"support@example.com"</span>
-  },
-  <span class="hljs-attr">"license"</span>: {
-    <span class="hljs-attr">"name"</span>: <span class="hljs-string">"Apache 2.0"</span>,
-    <span class="hljs-attr">"url"</span>: <span class="hljs-string">"https://www.apache.org/licenses/LICENSE-2.0.html"</span>
-  },
-  <span class="hljs-attr">"version"</span>: <span class="hljs-string">"1.0.1"</span>
-}
-</code></pre>
-<pre><code class="yml hljs" aria-busy="false">title: Sample Pet Store App
-summary: A pet store manager.
-description: This is a sample server for a pet store.
-termsOfService: https://example.com/terms/
-contact:
-  name: API Support
-  url: https://www.example.com/support
-  email: support@example.com
-license:
-  name: Apache 2.0
-  url: https://www.apache.org/licenses/LICENSE-2.0.html
-version: 1.0.1
-</code></pre>
+<section id="fixed-fields"><div class="header-wrapper"><h4 id="info-object-fixed-fields"><bdi class="secno">5.2.1 </bdi>Fixed Fields</h4><a class="self-link" href="#info-object-fixed-fields" aria-label="Permalink for Section 5.2.1"></a></div></section><section id="info-object-example"><div class="header-wrapper"><h4 id="x5-2-2-info-object-example"><bdi class="secno">5.2.2 </bdi>Info Object Example</h4><a class="self-link" href="#info-object-example" aria-label="Permalink for Section 5.2.2"></a></div>
 </section></section><section id="contact-object"><div class="header-wrapper"><h3 id="x5-3-contact-object"><bdi class="secno">5.3 </bdi>Contact Object</h3><a class="self-link" href="#contact-object" aria-label="Permalink for Section 5.3"></a></div>
-<p>Contact information for the exposed API.</p>
 <section id="fixed-fields-0"><div class="header-wrapper"><h4 id="x5-3-1-fixed-fields"><bdi class="secno">5.3.1 </bdi>Fixed Fields</h4><a class="self-link" href="#fixed-fields-0" aria-label="Permalink for Section 5.3.1"></a></div>
-<table>
-<thead>
-<tr>
-<th>Field Name</th>
-<th align="center">Type</th>
-<th>Description</th>
-</tr>
-</thead>
-<tbody><tr>
-<td>name</td>
-<td align="center"><code>string</code></td>
-<td>The identifying name of the contact person/organization.</td>
-</tr>
-<tr>
-<td>url</td>
-<td align="center"><code>string</code></td>
-<td>The URL pointing to the contact information. This <em class="rfc2119">MUST</em> be in the form of a URL.</td>
-</tr>
-<tr>
-<td>email</td>
-<td align="center"><code>string</code></td>
-<td>The email address of the contact person/organization. This <em class="rfc2119">MUST</em> be in the form of an email address.</td>
-</tr>
-</tbody></table>
-<p>This object <em class="rfc2119">MAY</em> be extended with <a href="#specification-extensions">Specification Extensions</a>.</p>
 </section><section id="contact-object-example"><div class="header-wrapper"><h4 id="x5-3-2-contact-object-example"><bdi class="secno">5.3.2 </bdi>Contact Object Example</h4><a class="self-link" href="#contact-object-example" aria-label="Permalink for Section 5.3.2"></a></div>
-<pre><code class="json hljs" aria-busy="false">{
-  <span class="hljs-attr">"name"</span>: <span class="hljs-string">"API Support"</span>,
-  <span class="hljs-attr">"url"</span>: <span class="hljs-string">"https://www.example.com/support"</span>,
-  <span class="hljs-attr">"email"</span>: <span class="hljs-string">"support@example.com"</span>
-}
-</code></pre>
-<pre><code class="yaml hljs" aria-busy="false">name: API Support
-url: https://www.example.com/support
-email: support@example.com
-</code></pre>
 </section></section><section id="license-object"><div class="header-wrapper"><h3 id="x5-4-license-object"><bdi class="secno">5.4 </bdi>License Object</h3><a class="self-link" href="#license-object" aria-label="Permalink for Section 5.4"></a></div>
-<p>License information for the API description.</p>
 <section id="fixed-fields-1"><div class="header-wrapper"><h4 id="x5-4-1-fixed-fields"><bdi class="secno">5.4.1 </bdi>Fixed Fields</h4><a class="self-link" href="#fixed-fields-1" aria-label="Permalink for Section 5.4.1"></a></div>
-<table>
-<thead>
-<tr>
-<th>Field Name</th>
-<th align="center">Type</th>
-<th>Description</th>
-</tr>
-</thead>
-<tbody><tr>
-<td>name</td>
-<td align="center"><code>string</code></td>
-<td><strong><em class="rfc2119">REQUIRED</em></strong>. The license name used for the API description.</td>
-</tr>
-<tr>
-<td>identifier</td>
-<td align="center"><code>string</code></td>
-<td>An <a href="https://spdx.org/licenses/">SPDX</a> license expression for the API description. The <code>identifier</code> field is mutually exclusive of the <code>url</code> field.</td>
-</tr>
-<tr>
-<td>url</td>
-<td align="center"><code>string</code></td>
-<td>A URL to the license used for the API description. This <em class="rfc2119">MUST</em> be in the form of a URL. The <code>url</code> field is mutually exclusive of the <code>identifier</code> field.</td>
-</tr>
-</tbody></table>
-<p>This object <em class="rfc2119">MAY</em> be extended with <a href="#specification-extensions">Specification Extensions</a>.</p>
 </section><section id="license-object-example"><div class="header-wrapper"><h4 id="x5-4-2-license-object-example"><bdi class="secno">5.4.2 </bdi>License Object Example</h4><a class="self-link" href="#license-object-example" aria-label="Permalink for Section 5.4.2"></a></div>
-<pre><code class="json hljs" aria-busy="false">{
-  <span class="hljs-attr">"name"</span>: <span class="hljs-string">"Apache 2.0"</span>,
-  <span class="hljs-attr">"identifier"</span>: <span class="hljs-string">"Apache-2.0"</span>
-}
-</code></pre>
-<pre><code class="yaml hljs" aria-busy="false">name: Apache 2.0
-identifier: Apache-2.0
-</code></pre>
 </section></section><section id="components-object"><div class="header-wrapper"><h3 id="x5-5-components-object"><bdi class="secno">5.5 </bdi>Components Object</h3><a class="self-link" href="#components-object" aria-label="Permalink for Section 5.5"></a></div>
-<p>TBD</p>
 </section><section id="import-object"><div class="header-wrapper"><h3 id="x5-6-import-object"><bdi class="secno">5.6 </bdi>Import Object</h3><a class="self-link" href="#import-object" aria-label="Permalink for Section 5.6"></a></div>
 <section id="fixed-fields-2"><div class="header-wrapper"><h4 id="x5-6-1-fixed-fields"><bdi class="secno">5.6.1 </bdi>Fixed Fields</h4><a class="self-link" href="#fixed-fields-2" aria-label="Permalink for Section 5.6.1"></a></div>
-<table>
-<thead>
-<tr>
-<th>Field Name</th>
-<th align="center">Type</th>
-<th>Description</th>
-</tr>
-</thead>
-<tbody><tr>
-<td>namespace</td>
-<td align="center"><code>string</code></td>
-<td><strong><em class="rfc2119">REQUIRED</em></strong>. A name, unique to the imports in this document, that is used to reference the imported document; this name <em class="rfc2119">MUST NOT</em> be 'self'.</td>
-</tr>
-<tr>
-<td>href</td>
-<td align="center"><code>IRI-reference</code> (without a fragment)</td>
-<td><strong><em class="rfc2119">REQUIRED</em></strong>. The IRI of the document to import; this IRI is not necessarily usable as a URL.</td>
-</tr>
-</tbody></table>
 </section></section><section id="api-shape"><div class="header-wrapper"><h3 id="x5-7-api-shape"><bdi class="secno">5.7 </bdi>API Shape</h3><a class="self-link" href="#api-shape" aria-label="Permalink for Section 5.7"></a></div>
-<p>API shape features are used to describe the capabilities of an API and the mechanism for interacting with those capabilties.</p>
 <section id="shape-fixed-fields"><div class="header-wrapper"><h4 id="x5-7-1-shape-fixed-fields"><bdi class="secno">5.7.1 </bdi>Shape Fixed Fields</h4><a class="self-link" href="#shape-fixed-fields" aria-label="Permalink for Section 5.7.1"></a></div>
-<table>
-<thead>
-<tr>
-<th>Field Name</th>
-<th align="center">Type</th>
-<th>Description</th>
-</tr>
-</thead>
-<tbody><tr>
-<td>operations</td>
-<td align="center">[ <a href="#operation-object">Operation Object</a> ]</td>
-<td>A list of operations defined for the API.</td>
-</tr>
-<tr>
-<td>webhooks</td>
-<td align="center">Map[<code>string</code>, <a href="#operation-object">Operation Object</a>]</td>
-<td>The incoming webhooks that <em class="rfc2119">MAY</em> be received as part of this API and that the API consumer <em class="rfc2119">MAY</em> choose to implement. Closely related to the <code>callbacks</code> feature, this section describes requests initiated other than by an API call, for example by an out of band registration. The key name is a unique string to refer to each webhook, while the [[#operation-object]] describes a request that may be initiated by the API provider and the expected responses.</td>
-</tr>
-</tbody></table>
 </section><section id="operation-object"><div class="header-wrapper"><h4 id="x5-7-2-operation-object"><bdi class="secno">5.7.2 </bdi>Operation Object</h4><a class="self-link" href="#operation-object" aria-label="Permalink for Section 5.7.2"></a></div>
-<p>Describes a single API operation.</p>
 <section id="fixed-fields-3"><div class="header-wrapper"><h5 id="x5-7-2-1-fixed-fields"><bdi class="secno">5.7.2.1 </bdi>Fixed Fields</h5><a class="self-link" href="#fixed-fields-3" aria-label="Permalink for Section 5.7.2.1"></a></div>
-<table>
-<thead>
-<tr>
-<th>Field Name</th>
-<th align="center">Type</th>
-<th>Description</th>
-</tr>
-</thead>
-<tbody><tr>
-<td>id</td>
-<td align="center"><code>string</code></td>
-<td>Unique string used to identify the operation. The id <em class="rfc2119">MUST</em> be unique among all operations described in the API. The Id value is <strong>case-sensitive</strong>. Tools and libraries <em class="rfc2119">MAY</em> use the Id to uniquely identify an operation, therefore, it is <em class="rfc2119">RECOMMENDED</em> to follow common programming naming conventions.</td>
-</tr>
-<tr>
-<td>method</td>
-<td align="center"><code>string</code></td>
-<td><strong><em class="rfc2119">REQUIRED</em></strong> The [HTTP] method used to invoke the operation.</td>
-</tr>
-<tr>
-<td>uriTemplate</td>
-<td align="center"><code>string</code></td>
-<td>A [<cite><a class="bibref" data-link-type="biblio" href="#bib-rfc6570" title="URI Template">RFC6570</a></cite>] URI template used to construct a URL to invoke the operation.</td>
-</tr>
-<tr>
-<td>summary</td>
-<td align="center"><code>string</code></td>
-<td>A short summary of what the operation does.</td>
-</tr>
-<tr>
-<td>description</td>
-<td align="center"><code>string</code></td>
-<td>A verbose explanation of the operation behavior. [<cite><a class="bibref" data-link-type="biblio" href="#bib-commonmark" title="CommonMark syntax">CommonMark</a></cite>] <em class="rfc2119">MAY</em> be used for rich text representation.</td>
-</tr>
-<tr>
-<td>parameters</td>
-<td align="center">[<a href="#parameter-object" class="respec-offending-element" title="Broken local reference found in document." id="respec-offender-broken-local-reference-found-in-document-19">Parameter Object</a> | <a href="#reference-object" class="respec-offending-element" title="Broken local reference found in document." id="respec-offender-broken-local-reference-found-in-document-20">Reference Object</a>]</td>
-<td>A list of parameters that are applicable for this operation. A unique parameter is defined by a combination of a <a href="#parameterName" class="respec-offending-element" title="Broken local reference found in document." id="respec-offender-broken-local-reference-found-in-document-21">name</a> and <a href="#parameterIn" class="respec-offending-element" title="Broken local reference found in document." id="respec-offender-broken-local-reference-found-in-document-22">location</a>. The list can use the <a href="#reference-object" class="respec-offending-element" title="Broken local reference found in document." id="respec-offender-broken-local-reference-found-in-document-23">Reference Object</a> to link to parameters that are defined at the <a href="#componentsParameters" class="respec-offending-element" title="Broken local reference found in document." id="respec-offender-broken-local-reference-found-in-document-24">OpenAPI Object's components/parameters</a>.</td>
-</tr>
-<tr>
-<td>requestBody</td>
-<td align="center"><a href="#request-body-object" class="respec-offending-element" title="Broken local reference found in document." id="respec-offender-broken-local-reference-found-in-document-25">Request Body Object</a> | <a href="#reference-object" class="respec-offending-element" title="Broken local reference found in document." id="respec-offender-broken-local-reference-found-in-document-26">Reference Object</a></td>
-<td>The request body applicable for this operation.  The <code>requestBody</code> is fully supported in HTTP methods where the HTTP 1.1 specification <a href="https://tools.ietf.org/html/rfc7231#section-4.3.1">RFC7231</a> has explicitly defined semantics for request bodies.  In other cases where the HTTP spec is vague (such as <a href="https://tools.ietf.org/html/rfc7231#section-4.3.1">GET</a>, <a href="https://tools.ietf.org/html/rfc7231#section-4.3.2">HEAD</a> and <a href="https://tools.ietf.org/html/rfc7231#section-4.3.5">DELETE</a>), <code>requestBody</code> is permitted but does not have well-defined semantics and <em class="rfc2119">SHOULD</em> be avoided if possible.</td>
-</tr>
-<tr>
-<td>responses</td>
-<td align="center"><a href="#responses-object" class="respec-offending-element" title="Broken local reference found in document." id="respec-offender-broken-local-reference-found-in-document-27">Responses Object</a></td>
-<td>The list of possible responses as they are returned from executing this operation.</td>
-</tr>
-<tr>
-<td>callbacks</td>
-<td align="center">Map[<code>string</code>, <a href="#callback-object" class="respec-offending-element" title="Broken local reference found in document." id="respec-offender-broken-local-reference-found-in-document-28">Callback Object</a> | <a href="#reference-object" class="respec-offending-element" title="Broken local reference found in document." id="respec-offender-broken-local-reference-found-in-document-29">Reference Object</a>]</td>
-<td>A map of possible out-of band callbacks related to the parent operation. The key is a unique identifier for the Callback Object. Each value in the map is a <a href="#callback-object" class="respec-offending-element" title="Broken local reference found in document." id="respec-offender-broken-local-reference-found-in-document-30">Callback Object</a> that describes a request that may be initiated by the API provider and the expected responses.</td>
-</tr>
-<tr>
-<td>security</td>
-<td align="center">[<a href="#security-requirement-object" class="respec-offending-element" title="Broken local reference found in document." id="respec-offender-broken-local-reference-found-in-document-31">Security Requirement Object</a>]</td>
-<td>A declaration of which security mechanisms can be used for this operation. The list of values includes alternative security requirement objects that can be used. Only one of the security requirement objects need to be satisfied to authorize a request. To make security optional, an empty security requirement (<code>{}</code>) can be included in the array. This definition overrides any declared top-level <a href="#oasSecurity" class="respec-offending-element" title="Broken local reference found in document." id="respec-offender-broken-local-reference-found-in-document-32"><code>security</code></a>. To remove a top-level security declaration, an empty array can be used.</td>
-</tr>
-<tr>
-<td>tags</td>
-<td align="center">[<code>string</code>]</td>
-<td>A list of tags for API documentation control. Tags can be used for logical grouping of operations by resources or any other qualifier.</td>
-</tr>
-<tr>
-<td>externalDocs</td>
-<td align="center"><a href="#external-documentation-object" class="respec-offending-element" title="Broken local reference found in document." id="respec-offender-broken-local-reference-found-in-document-33">External Documentation Object</a></td>
-<td>Additional external documentation for this operation.</td>
-</tr>
-<tr>
-<td>deprecated</td>
-<td align="center"><code>boolean</code></td>
-<td>Declares this operation to be deprecated. Consumers <em class="rfc2119">SHOULD</em> refrain from usage of the declared operation. Default value is <code>false</code>.</td>
-</tr>
-</tbody></table>
-<p>This object <em class="rfc2119">MAY</em> be extended with <a href="#specification-extensions">Specification Extensions</a>.</p>
 </section><section id="operation-object-example"><div class="header-wrapper"><h5 id="x5-7-2-2-operation-object-example"><bdi class="secno">5.7.2.2 </bdi>Operation Object Example</h5><a class="self-link" href="#operation-object-example" aria-label="Permalink for Section 5.7.2.2"></a></div>
-<pre><code class="json hljs" aria-busy="false">{
-  <span class="hljs-attr">"summary"</span>: <span class="hljs-string">"Updates a pet in the store with form data"</span>,
-  <span class="hljs-attr">"id"</span>: <span class="hljs-string">"updatePetWithForm"</span>,
-  <span class="hljs-attr">"parameters"</span>: [
-    {
-      <span class="hljs-attr">"name"</span>: <span class="hljs-string">"petId"</span>,
-      <span class="hljs-attr">"in"</span>: <span class="hljs-string">"path"</span>,
-      <span class="hljs-attr">"description"</span>: <span class="hljs-string">"ID of pet that needs to be updated"</span>,
-      <span class="hljs-attr">"required"</span>: <span class="hljs-literal">true</span>,
-      <span class="hljs-attr">"schema"</span>: {
-        <span class="hljs-attr">"type"</span>: <span class="hljs-string">"string"</span>
-      }
-    }
-  ],
-  <span class="hljs-attr">"requestBody"</span>: {
-    <span class="hljs-attr">"content"</span>: {
-      <span class="hljs-attr">"application/x-www-form-urlencoded"</span>: {
-        <span class="hljs-attr">"schema"</span>: {
-          <span class="hljs-attr">"type"</span>: <span class="hljs-string">"object"</span>,
-          <span class="hljs-attr">"properties"</span>: {
-            <span class="hljs-attr">"name"</span>: {
-              <span class="hljs-attr">"description"</span>: <span class="hljs-string">"Updated name of the pet"</span>,
-              <span class="hljs-attr">"type"</span>: <span class="hljs-string">"string"</span>
-            },
-            <span class="hljs-attr">"status"</span>: {
-              <span class="hljs-attr">"description"</span>: <span class="hljs-string">"Updated status of the pet"</span>,
-              <span class="hljs-attr">"type"</span>: <span class="hljs-string">"string"</span>
-            }
-          },
-          <span class="hljs-attr">"required"</span>: [<span class="hljs-string">"status"</span>]
-        }
-      }
-    }
-  },
-  <span class="hljs-attr">"responses"</span>: {
-    <span class="hljs-attr">"200"</span>: {
-      <span class="hljs-attr">"description"</span>: <span class="hljs-string">"Pet updated."</span>,
-      <span class="hljs-attr">"content"</span>: {
-        <span class="hljs-attr">"application/json"</span>: {},
-        <span class="hljs-attr">"application/xml"</span>: {}
-      }
-    },
-    <span class="hljs-attr">"405"</span>: {
-      <span class="hljs-attr">"description"</span>: <span class="hljs-string">"Method Not Allowed"</span>,
-      <span class="hljs-attr">"content"</span>: {
-        <span class="hljs-attr">"application/json"</span>: {},
-        <span class="hljs-attr">"application/xml"</span>: {}
-      }
-    }
-  },
-  <span class="hljs-attr">"tags"</span>: [
-    <span class="hljs-string">"pet"</span>
-  ],
-  <span class="hljs-attr">"security"</span>: [
-    {
-      <span class="hljs-attr">"petstore_auth"</span>: [
-        <span class="hljs-string">"write:pets"</span>,
-        <span class="hljs-string">"read:pets"</span>
-      ]
-    }
-  ]
-}
-</code></pre>
-<pre><code class="yaml hljs" aria-busy="false">tags:
-- pet
-summary: Updates a pet in the store with form data
-operationId: updatePetWithForm
-parameters:
-- name: petId
-  in: path
-  description: ID of pet that needs to be updated
-  required: true
-  schema:
-    type: string
-requestBody:
-  content:
-    'application/x-www-form-urlencoded':
-      schema:
-       type: object
-       properties:
-          name:
-            description: Updated name of the pet
-            type: string
-          status:
-            description: Updated status of the pet
-            type: string
-       required:
-         - status
-responses:
-  '200':
-    description: Pet updated.
-    content:
-      'application/json': {}
-      'application/xml': {}
-  '405':
-    description: Method Not Allowed
-    content:
-      'application/json': {}
-      'application/xml': {}
-security:
-- petstore_auth:
-  - write:pets
-  - read:pets
-</code></pre>
 </section></section></section><section id="api-deployment"><div class="header-wrapper"><h3 id="x5-8-api-deployment"><bdi class="secno">5.8 </bdi>API Deployment</h3><a class="self-link" href="#api-deployment" aria-label="Permalink for Section 5.8"></a></div>
-<p>API deployment features are used to describe where an API shape has been deployed and what kind of security schemes are used to protect it..</p>
 <section id="deployment-fixed-fields"><div class="header-wrapper"><h4 id="x5-8-1-deployment-fixed-fields"><bdi class="secno">5.8.1 </bdi>Deployment Fixed Fields</h4><a class="self-link" href="#deployment-fixed-fields" aria-label="Permalink for Section 5.8.1"></a></div>
-<table>
-<thead>
-<tr>
-<th>Field Name</th>
-<th align="center">Type</th>
-<th>Description</th>
-</tr>
-</thead>
-<tbody><tr>
-<td>deployments</td>
-<td align="center">map[ <a href="#deployment-object">Deployment Object</a>]</td>
-<td>A map of deployment Objects, which provide information about how to interact with a deployed instance of an API shape.</td>
-</tr>
-</tbody></table>
 </section><section id="deployment-example"><div class="header-wrapper"><h4 id="x5-8-2-deployment-example"><bdi class="secno">5.8.2 </bdi>Deployment Example</h4><a class="self-link" href="#deployment-example" aria-label="Permalink for Section 5.8.2"></a></div>
-<pre><code class="yaml hljs" aria-busy="false">deployments:
-    default: 
-      title: "prod - ca"
-      location: https://api.example.ca
-      security:
-          - basic: []
-</code></pre>
 </section><section id="deployment-object"><div class="header-wrapper"><h4 id="x5-8-3-deployment-object"><bdi class="secno">5.8.3 </bdi>Deployment Object</h4><a class="self-link" href="#deployment-object" aria-label="Permalink for Section 5.8.3"></a></div>
 <section id="deployment-fixed-fields-0"><div class="header-wrapper"><h5 id="x5-8-3-1-deployment-fixed-fields"><bdi class="secno">5.8.3.1 </bdi>Deployment Fixed Fields</h5><a class="self-link" href="#deployment-fixed-fields-0" aria-label="Permalink for Section 5.8.3.1"></a></div>
-<table>
-<thead>
-<tr>
-<th>Field Name</th>
-<th align="center">Type</th>
-<th>Description</th>
-</tr>
-</thead>
-<tbody><tr>
-<td>title</td>
-<td align="center"><code>string</code></td>
-<td><strong><em class="rfc2119">REQUIRED</em></strong>. The title of the deployment.</td>
-</tr>
-<tr>
-<td>location</td>
-<td align="center"><code>string</code></td>
-<td><strong><em class="rfc2119">REQUIRED</em></strong>. The URL of the deployed API.</td>
-</tr>
-<tr>
-<td>security</td>
-<td align="center">[<a href="#security-requirement-object" class="respec-offending-element" title="Broken local reference found in document." id="respec-offender-broken-local-reference-found-in-document-34">Security Requirement Object</a>]</td>
-<td>A declaration of which security mechanisms can be used with this API deployment. The list of values includes alternative security requirement objects that can be used. Only one of the security requirement objects need to be satisfied to authorize a request. Individual operations can override this definition. To make security optional, an empty security requirement (<code>{}</code>) can be included in the array.</td>
-</tr>
-</tbody></table>
 </section></section><section id="security-scheme-object"><div class="header-wrapper"><h4 id="x5-8-4-security-scheme-object"><bdi class="secno">5.8.4 </bdi>Security Scheme Object</h4><a class="self-link" href="#security-scheme-object" aria-label="Permalink for Section 5.8.4"></a></div>
-<p>Defines a security scheme that <em class="rfc2119">MAY</em> be used by a [[#security-requirements-object]].</p>
-<div class="note" id="issue-container-generatedID-3"><div role="heading" class="ednote-title marker" id="h-ednote-3" aria-level="2"><span>Editor's note</span></div><p class="">This security scheme is significantly different than that of OAS 3.0. It is based on the proposal here https://github.com/OAI/sig-security/blob/main/2021-05-19-New-Security-Definitions.md. We are seeing a significant increase in the number of security mechanism being used and proposed. The current design is unnecessarily complex and will get worse as more security mechansims are added. </p></div>
-
 <section id="fixed-fields-4"><div class="header-wrapper"><h5 id="x5-8-4-1-fixed-fields"><bdi class="secno">5.8.4.1 </bdi>Fixed Fields</h5><a class="self-link" href="#fixed-fields-4" aria-label="Permalink for Section 5.8.4.1"></a></div>
-<table>
-<thead>
-<tr>
-<th>Field Name</th>
-<th align="center">Type</th>
-<th>Description</th>
-</tr>
-</thead>
-<tbody><tr>
-<td>type</td>
-<td align="center"><code>string</code></td>
-<td><strong><em class="rfc2119">REQUIRED</em></strong>. The type of the security scheme. Valid values are <code>"apiKey"</code>, <code>"http"</code>, <code>"mutualTLS"</code>, <code>"oauth2"</code>, <code>"openIdConnect"</code>.</td>
-</tr>
-<tr>
-<td>description</td>
-<td align="center"><code>string</code></td>
-<td>A description for security scheme. <a href="https://spec.commonmark.org/">CommonMark syntax</a> <em class="rfc2119">MAY</em> be used for rich text representation.</td>
-</tr>
-<tr>
-<td>credential</td>
-<td align="center"><a href="#credential-object">Credential Object</a></td>
-<td><strong><em class="rfc2119">REQUIRED</em></strong>. An array of credential locations that convey how the credential can be included in the HTTP request. The array <em class="rfc2119">MUST</em> contain at least one element.</td>
-</tr>
-<tr>
-<td>config</td>
-<td align="center"><a href="#security-config-object">Security Config Object</a></td>
-<td><strong><em class="rfc2119">REQUIRED</em></strong>. An object with security configuration information specific to declared <code>type</code> value.</td>
-</tr>
-</tbody></table>
-<p>This object <em class="rfc2119">MAY</em> be extended with <a href="#specification-extensions">Specification Extensions</a>.</p>
 </section></section><section id="credential-object"><div class="header-wrapper"><h4 id="x5-8-5-credential-object"><bdi class="secno">5.8.5 </bdi>Credential Object</h4><a class="self-link" href="#credential-object" aria-label="Permalink for Section 5.8.5"></a></div>
-<p>A credential object specifies where in the HTTP request the credential is provided.</p>
 <section id="field-fields"><div class="header-wrapper"><h5 id="x5-8-5-1-field-fields"><bdi class="secno">5.8.5.1 </bdi>Field Fields</h5><a class="self-link" href="#field-fields" aria-label="Permalink for Section 5.8.5.1"></a></div>
-<table>
-<thead>
-<tr>
-<th>Field Name</th>
-<th>Type</th>
-<th>Description</th>
-</tr>
-</thead>
-<tbody><tr>
-<td>in</td>
-<td><code>string</code></td>
-<td><strong><em class="rfc2119">REQUIRED</em>.</strong> Specifies where in the request the credential is provided.  Valid values are: <code>body</code>, <code>cookie</code>, <code>header</code>, <code>path</code> and <code>query</code></td>
-</tr>
-<tr>
-<td>format</td>
-<td><code>regex</code></td>
-<td>Specifies the format of the credential.  Since in many cases, the credential is a subset of the raw value, <code>format</code> must be a regular expression that matches the complete value, and contains a single capturing group to match the actual value within the raw value.</td>
-</tr>
-<tr>
-<td>name</td>
-<td><code>string</code></td>
-<td><strong><em class="rfc2119">REQUIRED</em>.</strong> Specifies the name used to resolve the credential in the location provided by <code>in</code>.</td>
-</tr>
-</tbody></table>
-<div class="note" id="issue-container-generatedID-4"><div role="heading" class="ednote-title marker" id="h-ednote-4" aria-level="2"><span>Editor's note</span></div><p class="">We should discuss the use of regex in the format field. It is a powerful tool but can be difficult to use. We may want to consider a simpler format that is easier to use.</p></div>
-
 </section></section><section id="security-config-object"><div class="header-wrapper"><h4 id="x5-8-6-security-config-object"><bdi class="secno">5.8.6 </bdi>Security Config Object</h4><a class="self-link" href="#security-config-object" aria-label="Permalink for Section 5.8.6"></a></div>
-<p> The security config object is an abstract type that represents one of the concrete security configuration objects. The concrete type is determined by the <code>type</code> field of the parent <a href="#security-scheme-object">Security Scheme Object</a>.</p>
-<ul>
-<li><a href="#apikey-config-object">ApiKey Config Object</a></li>
-<li><a href="#oauth2-config-object">OAuth2 Config Object</a></li>
-<li><a href="#oidc-config-object">OIDC Config Object</a></li>
-<li><a href="#http-config-object">HTTP Config Object</a></li>
-</ul>
 <section id="apikey-config-object"><div class="header-wrapper"><h5 id="x5-8-6-1-apikey-config-object"><bdi class="secno">5.8.6.1 </bdi>ApiKey Config Object</h5><a class="self-link" href="#apikey-config-object" aria-label="Permalink for Section 5.8.6.1"></a></div>
-<p> TBD</p>
 </section><section id="oauth2-config-object"><div class="header-wrapper"><h5 id="x5-8-6-2-oauth2-config-object"><bdi class="secno">5.8.6.2 </bdi>OAuth2 Config Object</h5><a class="self-link" href="#oauth2-config-object" aria-label="Permalink for Section 5.8.6.2"></a></div>
-<p> TBD</p>
 </section><section id="oidc-config-object"><div class="header-wrapper"><h5 id="x5-8-6-3-oidc-config-object"><bdi class="secno">5.8.6.3 </bdi>OIDC Config Object</h5><a class="self-link" href="#oidc-config-object" aria-label="Permalink for Section 5.8.6.3"></a></div>
-<p> TBD</p>
 </section><section id="http-config-object"><div class="header-wrapper"><h5 id="x5-8-6-4-http-config-object"><bdi class="secno">5.8.6.4 </bdi>HTTP Config Object</h5><a class="self-link" href="#http-config-object" aria-label="Permalink for Section 5.8.6.4"></a></div>
-<p> TBD</p>
 </section></section></section></section><section id="appendix"><div class="header-wrapper"><h2 id="x6-appendix"><bdi class="secno">6. </bdi>Appendix</h2><a class="self-link" href="#appendix" aria-label="Permalink for Section 6."></a></div>
 </section><section class="appendix" id="revision-history"><div class="header-wrapper"><h2 id="a-revision-history"><bdi class="secno">A. </bdi>Revision History</h2><a class="self-link" href="#revision-history" aria-label="Permalink for Appendix A."></a></div>
 
@@ -1133,30 +347,13 @@ <h1 id="title" class="title">Moonwalk</h1>
 </tbody></table>
 </section>
 
-<section class="appendix" id="issue-summary"><div class="header-wrapper"><h2 id="b-issue-summary"><bdi class="secno">B. </bdi>Issue summary</h2><a class="self-link" href="#issue-summary" aria-label="Permalink for Appendix B."></a></div>
+<section class="appendix respec-offending-element" id="issue-summary" title="All sections must start with a `h2-6` element.">
 
 
   
 
 
-<ul><li><a href="#issue-container-number-131">Issue 131</a><span style="text-transform: none">: Can the Data Types section be replaced by a reference to the format registry?</span></li></ul></section>
-
-
-
-
-<p></p>
-<section id="references" class="appendix"><div class="header-wrapper"><h2 id="c-references"><bdi class="secno">C. </bdi>References</h2><a class="self-link" href="#references" aria-label="Permalink for Appendix C."></a></div><section id="normative-references"><div class="header-wrapper"><h3 id="c-1-normative-references"><bdi class="secno">C.1 </bdi>Normative references</h3><a class="self-link" href="#normative-references" aria-label="Permalink for Appendix C.1"></a></div>
-    
-    <dl class="bibliography"><dt id="bib-commonmark">[CommonMark]</dt><dd>
-      <a href="https://spec.commonmark.org/"><cite>CommonMark syntax</cite></a>.  John MacFarlane. Living Standard. URL: <a href="https://spec.commonmark.org/">https://spec.commonmark.org/</a>
-    </dd><dt id="bib-rfc2119">[RFC2119]</dt><dd>
-      <a href="https://www.rfc-editor.org/rfc/rfc2119"><cite>Key words for use in RFCs to Indicate Requirement Levels</cite></a>. S. Bradner.  IETF. March 1997. Best Current Practice. URL: <a href="https://www.rfc-editor.org/rfc/rfc2119">https://www.rfc-editor.org/rfc/rfc2119</a>
-    </dd><dt id="bib-rfc6570">[RFC6570]</dt><dd>
-      <a href="https://www.rfc-editor.org/rfc/rfc6570"><cite>URI Template</cite></a>. J. Gregorio; R. Fielding; M. Hadley; M. Nottingham; D. Orchard.  IETF. March 2012. Proposed Standard. URL: <a href="https://www.rfc-editor.org/rfc/rfc6570">https://www.rfc-editor.org/rfc/rfc6570</a>
-    </dd><dt id="bib-rfc8174">[RFC8174]</dt><dd>
-      <a href="https://www.rfc-editor.org/rfc/rfc8174"><cite>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</cite></a>. B. Leiba.  IETF. May 2017. Best Current Practice. URL: <a href="https://www.rfc-editor.org/rfc/rfc8174">https://www.rfc-editor.org/rfc/rfc8174</a>
-    </dd></dl>
-  </section></section><p role="navigation" id="back-to-top">
+</section><p role="navigation" id="back-to-top">
     <a href="#title"><abbr title="Back to Top">↑</abbr></a>
   </p><script id="respec-dfn-panel">(() => {
 // @ts-check
diff --git a/specification/moonwalk-source.md b/specification/moonwalk-source.md
index 6937f9e..382d553 100644
--- a/specification/moonwalk-source.md
+++ b/specification/moonwalk-source.md
@@ -37,655 +37,166 @@ This document is licensed under [The Apache License, Version 2.0](https://www.ap
 
 ## Introduction
 
-The OpenAPI Specification (OAS) defines a standard, language-agnostic interface to HTTP APIs which allows both humans and computers to discover and understand the capabilities of the service without access to source code, documentation, or through network traffic inspection. When properly defined, a consumer can understand and interact with the remote service with a minimal amount of implementation logic.
-
-An OpenAPI definition can then be used by documentation generation tools to display the API, code generation tools to generate servers and clients in various programming languages, testing tools, and many other use cases.
-
 ## Definitions
 
 ##### OpenAPI Document
-An OpenAPI Description (OAD) formally describes the surface of an API and its semantics. It is composed of an [entry document](#documentStructure) and any/all of its referenced documents. 
-<p class="ednote">Need to define what are the required top level properties</p>
 
 ##### Media Types
-Media type definitions are spread across several resources.
-The media type definitions SHOULD be in compliance with [RFC6838](https://tools.ietf.org/html/rfc6838).
-
-Some examples of possible media type definitions:
-```shell
-  text/plain; charset=utf-8
-  application/json
-  application/vnd.github+json
-  application/vnd.github.v3+json
-  application/vnd.github.v3.raw+json
-  application/vnd.github.v3.text+json
-  application/vnd.github.v3.html+json
-  application/vnd.github.v3.full+json
-  application/vnd.github.v3.diff
-  application/vnd.github.v3.patch
-```
+
 ##### HTTP Status Codes
-The HTTP Status Codes are used to indicate the status of the executed operation. 
-Status codes SHOULD be selected from the available status codes registered in the [IANA Status Code Registry](https://www.iana.org/assignments/http-status-codes/http-status-codes.xhtml).
 
 ## Conventions
 
 ### Versions {#oas-version}
 
-The OpenAPI Specification is versioned using a `major`.`minor`.`patch` versioning scheme. The `major`.`minor` portion of the version string (for example `3.1`) SHALL designate the OAS feature set. *`.patch`* versions address errors in, or provide clarifications to, this document, not the feature set. Tooling which supports OAS 3.1 SHOULD be compatible with all OAS 3.1.\* versions. The patch version SHOULD NOT be considered by tooling, making no distinction between `3.1.0` and `3.1.1` for example.
-
-Occasionally, non-backwards compatible changes may be made in `minor` versions of the OAS where impact is believed to be low relative to the benefit provided.
-
-An OpenAPI document compatible with OAS 3.\*.\* contains a required [`openapi`](#oasVersion) field which designates the version of the OAS that it uses.
-
 ### Format
 
-An OpenAPI document that conforms to the OpenAPI Specification is itself a JSON object, which may be represented either in JSON or YAML format.
-
-For example, if a field has an array value, the JSON array representation will be used:
-
-```json
-{
-   "field": [ 1, 2, 3 ]
-}
-```
-All field names in the specification are **case sensitive**.
-This includes all fields that are used as keys in a map, except where explicitly noted that keys are **case insensitive**.
-
-The schema exposes two types of fields: Fixed fields, which have a declared name, and Patterned fields, which declare a regex pattern for the field name.
-
-Patterned fields MUST have unique names within the containing object. 
-
-In order to preserve the ability to round-trip between YAML and JSON formats, YAML version [1.2](https://yaml.org/spec/1.2/spec.html) is RECOMMENDED along with some additional constraints:
-
-- Tags MUST be limited to those allowed by the [JSON Schema ruleset](https://yaml.org/spec/1.2/spec.html#id2803231).
-- Keys used in YAML maps MUST be limited to a scalar string, as defined by the [YAML Failsafe schema ruleset](https://yaml.org/spec/1.2/spec.html#id2802346).
-
-**Note:** While APIs may be defined by OpenAPI documents in either YAML or JSON format, the API request and response bodies and other content are not required to be JSON or YAML.
-
 ### Data Types
 
-<p class="issue" data-number="131" >Replace this paragraph with a reference to the format registry</p>
 
 #### Working With Binary Data
 
-The OAS can describe either _raw_ or _encoded_ binary data.
-
-* **raw binary** is used where unencoded binary data is allowed, such as when sending a binary payload as the entire HTTP message body, or as part of a `multipart/*` payload that allows binary parts
-* **encoded binary** is used where binary data is embedded in a text-only format such as `application/json` or `application/x-www-form-urlencoded` (either as a message body or in the URL query string).
-
-In the following table showing how to use Schema Object keywords for binary data, we use `image/png` as an example binary media type.  Any binary media type, including `application/octet-stream`, is sufficient to indicate binary content.
-
-Keyword | Raw | Encoded | Comments
-------- | --- | ------- | --------
-`type`  | _omit_ | `string` | raw binary is [outside of `type`](https://datatracker.ietf.org/doc/html/draft-bhutton-json-schema-00#section-4.2.3)
-`contentMediaType` | `image/png` | `image/png` | can sometimes be omitted if redundant (see below)
-`contentEncoding`  | _omit_ | `base64`&nbsp;or&nbsp;`base64url` | other encodings are [allowed](https://datatracker.ietf.org/doc/html/draft-bhutton-json-schema-validation-00#section-8.3)
-
-Note that the encoding indicated by `contentEncoding`, which inflates the size of data in order to represent it as 7-bit ASCII text, is unrelated to HTTP's `Content-Encoding` header, which indicates whether and how a message body has been compressed and is applied after all content serialization described in this section has occurred.  Since HTTP allows unencoded binary message bodies, there is no standardized HTTP header for indicating base64 or similar encoding of an entire message body.
-
-Using a `contentEncoding` of `base64url` ensures that URL encoding (as required in the query string and in message bodies of type `application/x-www-form-urlencoded`) does not need to further encode any part of the already-encoded binary data.
-
-The `contentMediaType` keyword is redundant if the media type is already set:
-
-* as the key for a [`MediaType Object`](#mediaTypeObject)
-* in the `contentType` field of an [`Encoding Object`](#encodingObject)
-
-If the Schema Object will be processed by a non-OAS-aware JSON Schema implementation, it may be useful to include `contentMediaType` even if it is redundant.  However, if `contentMediaType` contradicts a relevant Media Type Object or Encoding Object, then `contentMediaType` SHALL be ignored.
-
-The `maxLength` keyword MAY be used to set an expected upper bound on the length of a streaming payload.  The keyword can be applied to either string data, including encoded binary data, or to unencoded binary data.  For unencoded binary, the length is the number of octets.
 
 ##### Migrating binary descriptions from OAS 3.0
-The following table shows how to migrate from OAS 3.0 binary data descriptions, continuing to use `image/png` as the example binary media type:
-
-OAS < 3.1 | OAS 3.1 | Comments
---------- | ------- | --------
-`type: string`<br />`format: binary` | `contentMediaType: image/png` | if redundant, can be omitted, often resulting in an empty Schema Object
-`type: string`<br />`format: byte`   | `type: string`<br />`contentMediaType: image/png`<br />`contentEncoding: base64` | note that `base64url` can be used to avoid re-encoding the base64 string to be URL-safe
 
 
 ### Rich Text Formatting
-Throughout the specification `description` fields are noted as supporting CommonMark markdown formatting.
-Where OpenAPI tooling renders rich text it MUST support, at a minimum, markdown syntax as described by [CommonMark 0.27](https://spec.commonmark.org/0.27/). Tooling MAY choose to ignore some CommonMark features to address security concerns. 
 
 ### Relative References in URIs
 
-Unless specified otherwise, all properties that are URIs MAY be relative references as defined by [RFC3986](https://tools.ietf.org/html/rfc3986#section-4.2).
-
-Relative references, including those in [`Reference Objects`](#referenceObject), [`PathItem Object`](#pathItemObject) `$ref` fields, [`Link Object`](#linkObject) `operationRef` fields and [`Example Object`](#exampleObject) `externalValue` fields, are resolved using the referring document as the Base URI according to [RFC3986](https://tools.ietf.org/html/rfc3986#section-5.2).
-
-If a URI contains a fragment identifier, then the fragment should be resolved per the fragment resolution mechanism of the referenced document.  If the representation of the referenced document is JSON or YAML, then the fragment identifier SHOULD be interpreted as a JSON-Pointer as per [RFC6901](https://tools.ietf.org/html/rfc6901).
-
-Relative references in [`Schema Objects`](#schemaObject), including any that appear as `$id` values, use the nearest parent `$id` as a Base URI, as described by [JSON Schema Specification Draft 2020-12](https://tools.ietf.org/html/draft-bhutton-json-schema-00#section-8.2).  If no parent schema contains an `$id`, then the Base URI MUST be determined according to [RFC3986](https://tools.ietf.org/html/rfc3986#section-5.1).
 
 ### Relative References in URLs
 
-Unless specified otherwise, all properties that are URLs MAY be relative references as defined by [RFC3986](https://tools.ietf.org/html/rfc3986#section-4.2).
-Unless specified otherwise, relative references are resolved using the URLs defined in the [`Server Object`](#serverObject) as a Base URL. Note that these themselves MAY be relative to the referring document.
 
 ### Referencing Imports
 
 #### Using Imported Names
 
-<p class="ednote">This syntax comes directly from the deployments examples.  It does involve values that are either objects (inline) or strings (imported names) which might be of concern to developers in strictly typed languages.
-</p>
-
-Imported names are used in specific contexts that require a particular type of Object.  The syntax for using a name is:
-
-```YAML
-  <fieldName>: <namespace>:<componentName>
-```
-
-where `<namespace>` is replaced by the namespace from an Import Object in the current document, and `<componentName>` MUST but the name of an Object in the imported document's Components Object, under the appropriate semantic type section.  Therefore:
-
-```YAML
-openapi: 4.0.0
-self: https://example.com/fooComponents
-components:
-  pathItems:
-    Foos: {...}
-  schemas:
-    Foos: {...}
-```
-```YAML
-openapi: 4.0.0
-self: https://example.com/fooPaths
-components:
-  pathItems:
-    Bars: {...}
-imports:
-- namespace: foo
-  href: fooComponents
-paths:
-  /foos: foo:Foos
-  /bars: self:Bars
-```
-
-In this example, the import `href` "fooComponents" is an IRI-reference resolved against `self` as a base IRI, producing `https://example.com/fooComponents`.  Since the `foo:Foos` is found where a Path Item Object is expected, the "Foos" entry under `pathItems` is used rather than the identically-named Schema Object under `schemas`.
-
-The `/bars` entry shows how to use a component from the current document with the reserved `self` namespace.
 
 #### Referencing a Complete Document
 
-Some fields require a document-level reference, such as connecting a deployment to its shape.  In that case, only the namespace is used, without the component name separator:
-
-```YAML
-  <fieldName>: <namespace>
-```
-
-This form MUST only be used when it makes sense to talk about the effect of the complete document, rather than components within the document.
 
 #### Locating and Loading Imported Resources
 
-<p class="ednote">The requirements in this section are phrased to allow, but not require, compliant implementations to delegate all I/O to applications.  It should also be possible to implement resolvers separate from the core OAS support, somewhat like reference resolvers/removers but with much better UX.
-</p>
-
-Implementations MUST support two methods of resolving imports:
-
-* matching the import IRI to the resource's self-assigned IRI
-* treating the import IRI as a retrieval URL
-
-Note that interacting with local files is equivalent to retrieval using `file:` IRIs ([RFC 8089])(https://datatracker.ietf.org/doc/html/rfc8089).
-
-As implementations cannot determine a self-assigned IRI without parsing the resource, they MUST support pre-loading resources or otherwise configuring some mechanism to load likely candidates on demand.
-
-Implementations MAY directly support URL retrieval.  Those that do SHOULD support URI schemes most relevant to their environment, such as `file:` for local access and `https:` for network access.
-
-Implementations that do not support URL retrieval MUST support associating a retrieval URL with each resource.
 
 #### Security Considerations for URL Retrieval
 
-<p class="ednote">TODO</p>
 
 
 ### Specification Extensions
 
-While the OpenAPI Specification tries to accommodate most use cases, additional data can be added to extend the specification at certain points.
-
-The extensions properties are implemented as patterned fields that are always prefixed by `"x-"`.
-
-Field Pattern | Type | Description
----|:---:|---
-^x- | Any | Allows extensions to the OpenAPI Schema. The field name MUST begin with `x-`, for example, `x-internal-id`. Field names beginning `x-oai-` and `x-oas-` are reserved for uses defined by the [OpenAPI Initiative](https://www.openapis.org/). The value can be `null`, a primitive, an array or an object.
-
-The extensions may or may not be supported by the available tooling, but those may be extended as well to add requested support (if tools are internal or open-sourced).
 
 ## Document Processing
 
 #### 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
-
-Implementations that parse referenced fragments of OpenAPI content without regard for the content of the rest of the containing document will miss keywords that change the meaning and behavior of the reference target.
-In particular, failing to take into account keywords that change the base URI introduces security risks by causing references to resolve to unintended URIs, with unpredictable results.
-While some implementations support this sort of parsing due to the requirements of past versions of this specification, in version 3.1, the result of parsing fragments in isolation is _undefined_ and likely to contradict the requirements of this specification.
-
-While it is possible to structure certain OpenAPI Descriptions to ensure that they will behave correctly when references are parsed as isolated fragments, depending on this is NOT RECOMMENDED.
-This specification does not explicitly enumerate the conditions under which such behavior is safe, and provides no guarantee for continued safety in any future versions of the OAS.
-
-A special case of parsing fragments of OAS content would be if such fragments are embedded in another format, referred to as an _embedding format_ with respect to the OAS.
-Note that the OAS itself is an embedding format with respect to JSON Schema, which is embedded as Schema Objects.
-It is the responsibility of an embedding format to define how to parse embedded content, and OAS implementations that do not document support for an embedding format cannot be expected to parse embedded OAS content correctly.
 
 #### 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:
-
-* As a full OpenAPI Description document (an [OpenAPI Object](#oasObject) taking up an entire document)
-* As the Object type implied by its parent Object within the document
-* As a reference target, with the Object type matching the reference source's context
-
-If the same JSON/YAML object is parsed multiple times and the respective contexts require it to be parsed as _different_ Object types, the resulting behavior is _implementation defined_, and MAY be treated as an error if detected.  An example would be referencing an empty Schema Object under `#/components/schemas` where a Path Item Object is expected, as an empty object is valid for both types.  For maximum interoperability, it is RECOMMENDED that OpenAPI Description authors avoid such scenarios.
 
 #### Resolving Implicit Connections
 
 
 #### Undefined and Implementation-Defined Behavior
 
-This specification deems certain situations to have either _undefined_ or _implementation-defined_ behavior.
-
-Behavior described as _undefined_ is likely, at least in some circumstances, to result in outcomes that contradict the specification.
-This description is used when detecting the contradiction is impossible or impractical.
-Implementations MAY support undefined scenarios for historical reasons, including ambiguous text in prior versions of the specification.
-This support might produce correct outcomes in many cases, but relying on it is NOT RECOMMENDED as there is no guarantee that it will work across all tools or with future specification versions, even if those versions are otherwise strictly compatible with this one.
-
-Behavior described as _implementation-defined_ allows implementations to choose which of several different-but-compliant approaches to a requirement to implement.
-This documents ambiguous requirements that API description authors are RECOMMENDED to avoid in order to maximize interoperability.
-Unlike undefined behavior, it is safe to rely on implementation-defined behavior if _and only if_ it can be guaranteed that all relevant tools support the same behavior.
 
 
 ## OpenAPI Document Structure
 
-The features of an OpenAPI description can be divided into two main categories: API shape and API deployment. The shape of an API can be described independently of deployment.  An API shape could be deployed many times, but a deployment must reference a single API shape.
-
-The fields that represent the API shape and API deployment both live at the root of an OpenAPI document.
 
 ##### General Fixed Fields
 
-Field Name | Type | Description
----|:---:|---
-openapi | `string` | **REQUIRED**. This string MUST be the [version number](#versions) of the OpenAPI Specification that the OpenAPI document uses. The `openapi` field SHOULD be used by tooling to interpret the OpenAPI document. This is *not* related to the API [`info.version`](#infoVersion) string.
-self | `IRI-reference` (without a fragment) | Sets the IRI of this document, which also serves as its base IRI in accordance with [RFC 3986 §5.1.1](https://www.rfc-editor.org/rfc/rfc3986#section-5.1.1); the value MUST NOT be the empty string
-info | [Info Object](#info-object) | **REQUIRED**. Provides metadata about the API. The metadata MAY be used by tooling as required.
- jsonSchemaDialect | `string` | The default value for the `$schema` keyword within [Schema Objects](#schema-object) contained within this OAS document. This MUST be in the form of a URI.
-imports |  [ [Import Object](#import-object) ]  | A list of resources to import, from which all references within this document MUST be resolved.
-components | [Components Object](#components-object) | An element to hold various schemas for the document.
-tags | [ [Tag Object](#tag-object) ] | A list of tags used by the document with additional metadata. The order of the tags can be used to reflect on their order by the parsing tools. Not all tags that are used by the [Operation Object](#operation-object) must be declared. The tags that are not declared MAY be organized randomly or based on the tools' logic. Each tag name in the list MUST be unique.
-
-The value of `self` is an _identifier_, and not necessarily a _locator_.  The value need not be usable as a URL, and even if it is, the document need not be accessible at that location.
-
-This object MAY be extended with [Specification Extensions](#specification-extensions).
 
 #### Info Object
 
-The object provides metadata about the API.
-The metadata MAY be used by the clients if needed, and MAY be presented in editing or documentation generation tools for convenience.
 
 ##### Fixed Fields {#info-object-fixed-fields}
 
-Field Name | Type | Description
----|:---:|---
-title | `string` | **REQUIRED**. The title of the API.
-summary | `string` | A short summary of the API.
-description | `string` | A description of the API. [CommonMark syntax](https://spec.commonmark.org/) MAY be used for rich text representation.
-termsOfService | `string` | A URL to the Terms of Service for the API. This MUST be in the form of a URL.
-contact | [Contact Object](#contact-object) | The contact information for the exposed API.
-license | [License Object](#license-object) | The license information for the exposed API.
-version | `string` | **REQUIRED**. The version of the OpenAPI description (which is distinct from the [OpenAPI Specification version](#oas-version) or the API implementation version).
-externalDocs | [External Documentation Object](#externalDocumentationObject) | Additional external documentation.
-
-This object MAY be extended with [Specification Extensions](#specification-extensions).
 
 ##### Info Object Example
 
-```json
-{
-  "title": "Sample Pet Store App",
-  "summary": "A pet store manager.",
-  "description": "This is a sample server for a pet store.",
-  "termsOfService": "https://example.com/terms/",
-  "contact": {
-    "name": "API Support",
-    "url": "https://www.example.com/support",
-    "email": "support@example.com"
-  },
-  "license": {
-    "name": "Apache 2.0",
-    "url": "https://www.apache.org/licenses/LICENSE-2.0.html"
-  },
-  "version": "1.0.1"
-}
-```
-
-```yml
-title: Sample Pet Store App
-summary: A pet store manager.
-description: This is a sample server for a pet store.
-termsOfService: https://example.com/terms/
-contact:
-  name: API Support
-  url: https://www.example.com/support
-  email: support@example.com
-license:
-  name: Apache 2.0
-  url: https://www.apache.org/licenses/LICENSE-2.0.html
-version: 1.0.1
-```
 
 #### Contact Object
 
-Contact information for the exposed API.
 
 ##### Fixed Fields
 
-Field Name | Type | Description
----|:---:|---
-name | `string` | The identifying name of the contact person/organization.
-url | `string` | The URL pointing to the contact information. This MUST be in the form of a URL.
-email | `string` | The email address of the contact person/organization. This MUST be in the form of an email address.
-
-This object MAY be extended with [Specification Extensions](#specification-extensions).
 
 ##### Contact Object Example
 
-```json
-{
-  "name": "API Support",
-  "url": "https://www.example.com/support",
-  "email": "support@example.com"
-}
-```
-
-```yaml
-name: API Support
-url: https://www.example.com/support
-email: support@example.com
-```
 
 #### License Object
 
-License information for the API description.
 
 ##### Fixed Fields
 
-Field Name | Type | Description
----|:---:|---
-name | `string` | **REQUIRED**. The license name used for the API description.
-identifier | `string` | An [SPDX](https://spdx.org/licenses/) license expression for the API description. The `identifier` field is mutually exclusive of the `url` field.
-url | `string` | A URL to the license used for the API description. This MUST be in the form of a URL. The `url` field is mutually exclusive of the `identifier` field.
-
-This object MAY be extended with [Specification Extensions](#specification-extensions).
 
 ##### License Object Example
 
-```json
-{
-  "name": "Apache 2.0",
-  "identifier": "Apache-2.0"
-}
-```
-
-```yaml
-name: Apache 2.0
-identifier: Apache-2.0
-```
 
 #### Components Object
 
-TBD
 
 #### Import Object
 
 ##### Fixed Fields
 
-Field Name | Type | Description
----|:---:|---
-namespace | `string` | **REQUIRED**. A name, unique to the imports in this document, that is used to reference the imported document; this name MUST NOT be 'self'.
-href | `IRI-reference` (without a fragment) | **REQUIRED**. The IRI of the document to import; this IRI is not necessarily usable as a URL.
 
 
 ### API Shape
 
-API shape features are used to describe the capabilities of an API and the mechanism for interacting with those capabilties.
 
 ##### Shape Fixed Fields
 
-Field Name | Type | Description
----|:---:|---
-operations | [ [Operation Object](#operation-object) ] | A list of operations defined for the API.
-webhooks | Map[`string`, [Operation Object](#operation-object)] | The incoming webhooks that MAY be received as part of this API and that the API consumer MAY choose to implement. Closely related to the `callbacks` feature, this section describes requests initiated other than by an API call, for example by an out of band registration. The key name is a unique string to refer to each webhook, while the [[#operation-object]] describes a request that may be initiated by the API provider and the expected responses. 
-
 
 #### Operation Object
 
-Describes a single API operation.
 
 ##### Fixed Fields
 
-Field Name | Type | Description
----|:---:|---
-id | `string` | Unique string used to identify the operation. The id MUST be unique among all operations described in the API. The Id value is **case-sensitive**. Tools and libraries MAY use the Id to uniquely identify an operation, therefore, it is RECOMMENDED to follow common programming naming conventions.
-method | `string` | **REQUIRED** The [HTTP] method used to invoke the operation.
-uriTemplate | `string` | A [[RFC6570]] URI template used to construct a URL to invoke the operation.
-summary | `string` | A short summary of what the operation does.
-description | `string` | A verbose explanation of the operation behavior. [[CommonMark]] MAY be used for rich text representation.
-parameters | [[Parameter Object](#parameter-object) \| [Reference Object](#reference-object)] | A list of parameters that are applicable for this operation. A unique parameter is defined by a combination of a [name](#parameterName) and [location](#parameterIn). The list can use the [Reference Object](#reference-object) to link to parameters that are defined at the [OpenAPI Object's components/parameters](#componentsParameters).
-requestBody | [Request Body Object](#request-body-object) \| [Reference Object](#reference-object) | The request body applicable for this operation.  The `requestBody` is fully supported in HTTP methods where the HTTP 1.1 specification [RFC7231](https://tools.ietf.org/html/rfc7231#section-4.3.1) has explicitly defined semantics for request bodies.  In other cases where the HTTP spec is vague (such as [GET](https://tools.ietf.org/html/rfc7231#section-4.3.1), [HEAD](https://tools.ietf.org/html/rfc7231#section-4.3.2) and [DELETE](https://tools.ietf.org/html/rfc7231#section-4.3.5)), `requestBody` is permitted but does not have well-defined semantics and SHOULD be avoided if possible.
-responses | [Responses Object](#responses-object) | The list of possible responses as they are returned from executing this operation.
-callbacks | Map[`string`, [Callback Object](#callback-object) \| [Reference Object](#reference-object)] | A map of possible out-of band callbacks related to the parent operation. The key is a unique identifier for the Callback Object. Each value in the map is a [Callback Object](#callback-object) that describes a request that may be initiated by the API provider and the expected responses.
-security | [[Security Requirement Object](#security-requirement-object)] | A declaration of which security mechanisms can be used for this operation. The list of values includes alternative security requirement objects that can be used. Only one of the security requirement objects need to be satisfied to authorize a request. To make security optional, an empty security requirement (`{}`) can be included in the array. This definition overrides any declared top-level [`security`](#oasSecurity). To remove a top-level security declaration, an empty array can be used.
-tags | [`string`] | A list of tags for API documentation control. Tags can be used for logical grouping of operations by resources or any other qualifier.
-externalDocs | [External Documentation Object](#external-documentation-object) | Additional external documentation for this operation.
-deprecated | `boolean` | Declares this operation to be deprecated. Consumers SHOULD refrain from usage of the declared operation. Default value is `false`.
-
-This object MAY be extended with [Specification Extensions](#specification-extensions).
 
 ##### Operation Object Example
 
-```json
-{
-  "summary": "Updates a pet in the store with form data",
-  "id": "updatePetWithForm",
-  "parameters": [
-    {
-      "name": "petId",
-      "in": "path",
-      "description": "ID of pet that needs to be updated",
-      "required": true,
-      "schema": {
-        "type": "string"
-      }
-    }
-  ],
-  "requestBody": {
-    "content": {
-      "application/x-www-form-urlencoded": {
-        "schema": {
-          "type": "object",
-          "properties": {
-            "name": {
-              "description": "Updated name of the pet",
-              "type": "string"
-            },
-            "status": {
-              "description": "Updated status of the pet",
-              "type": "string"
-            }
-          },
-          "required": ["status"]
-        }
-      }
-    }
-  },
-  "responses": {
-    "200": {
-      "description": "Pet updated.",
-      "content": {
-        "application/json": {},
-        "application/xml": {}
-      }
-    },
-    "405": {
-      "description": "Method Not Allowed",
-      "content": {
-        "application/json": {},
-        "application/xml": {}
-      }
-    }
-  },
-  "tags": [
-    "pet"
-  ],
-  "security": [
-    {
-      "petstore_auth": [
-        "write:pets",
-        "read:pets"
-      ]
-    }
-  ]
-}
-```
-
-```yaml
-tags:
-- pet
-summary: Updates a pet in the store with form data
-operationId: updatePetWithForm
-parameters:
-- name: petId
-  in: path
-  description: ID of pet that needs to be updated
-  required: true
-  schema:
-    type: string
-requestBody:
-  content:
-    'application/x-www-form-urlencoded':
-      schema:
-       type: object
-       properties:
-          name:
-            description: Updated name of the pet
-            type: string
-          status:
-            description: Updated status of the pet
-            type: string
-       required:
-         - status
-responses:
-  '200':
-    description: Pet updated.
-    content:
-      'application/json': {}
-      'application/xml': {}
-  '405':
-    description: Method Not Allowed
-    content:
-      'application/json': {}
-      'application/xml': {}
-security:
-- petstore_auth:
-  - write:pets
-  - read:pets
-```
 
 
 ### API Deployment
 
-API deployment features are used to describe where an API shape has been deployed and what kind of security schemes are used to protect it..
 
 ##### Deployment Fixed Fields
 
-Field Name | Type | Description
----|:---:|---
-deployments | map[ [Deployment Object](#deployment-object)] | A map of deployment Objects, which provide information about how to interact with a deployed instance of an API shape.
 
 ##### Deployment Example
 
-```yaml
-deployments:
-    default: 
-      title: "prod - ca"
-      location: https://api.example.ca
-      security:
-          - basic: []
-```
 
 #### Deployment Object
 
 ##### Deployment Fixed Fields
 
-Field Name | Type | Description
----|:---:|---
-title | `string` | **REQUIRED**. The title of the deployment.
-location | `string` | **REQUIRED**. The URL of the deployed API.
-security | [[Security Requirement Object](#security-requirement-object)] | A declaration of which security mechanisms can be used with this API deployment. The list of values includes alternative security requirement objects that can be used. Only one of the security requirement objects need to be satisfied to authorize a request. Individual operations can override this definition. To make security optional, an empty security requirement (`{}`) can be included in the array.
 
 #### Security Scheme Object
 
-Defines a security scheme that MAY be used by a [[#security-requirements-object]].
-
-<p class="ednote">This security scheme is significantly different than that of OAS 3.0. It is based on the proposal here https://github.com/OAI/sig-security/blob/main/2021-05-19-New-Security-Definitions.md. We are seeing a significant increase in the number of security mechanism being used and proposed. The current design is unnecessarily complex and will get worse as more security mechansims are added. </p>
 
 ##### Fixed Fields
-Field Name | Type | Description
----|:---:|---
-type | `string` |  **REQUIRED**. The type of the security scheme. Valid values are `"apiKey"`, `"http"`, `"mutualTLS"`, `"oauth2"`, `"openIdConnect"`.
-description | `string` | A description for security scheme. [CommonMark syntax](https://spec.commonmark.org/) MAY be used for rich text representation.
-credential | [Credential Object](#credential-object) |  **REQUIRED**. An array of credential locations that convey how the credential can be included in the HTTP request. The array MUST contain at least one element. 
-config | [Security Config Object](#security-config-object)  |  **REQUIRED**. An object with security configuration information specific to declared `type` value.
-
-This object MAY be extended with [Specification Extensions](#specification-extensions).
 
 #### Credential Object
 
-A credential object specifies where in the HTTP request the credential is provided.
 
 ##### Field Fields
 
-| Field Name | Type |  Description |
-| ---------- | ---- |  ----------- |
-| in | `string` | **REQUIRED.** Specifies where in the request the credential is provided.  Valid values are: `body`, `cookie`, `header`, `path` and `query` |
-| format | `regex` |  Specifies the format of the credential.  Since in many cases, the credential is a subset of the raw value, `format` must be a regular expression that matches the complete value, and contains a single capturing group to match the actual value within the raw value. |
-| name | `string` | **REQUIRED.** Specifies the name used to resolve the credential in the location provided by `in`. |
-
-<p class="ednote">We should discuss the use of regex in the format field. It is a powerful tool but can be difficult to use. We may want to consider a simpler format that is easier to use.</p>
 
 #### Security Config Object
 
- The security config object is an abstract type that represents one of the concrete security configuration objects. The concrete type is determined by the `type` field of the parent [Security Scheme Object](#security-scheme-object).
-
-  - [ApiKey Config Object](#apikey-config-object)
-  - [OAuth2 Config Object](#oauth2-config-object)
-  - [OIDC Config Object](#oidc-config-object)
-  - [HTTP Config Object](#http-config-object)
-
 ##### ApiKey Config Object
 
- TBD
 
 ##### OAuth2 Config Object
 
- TBD
 
  ##### OIDC Config Object
 
- TBD
 
  ##### HTTP Config Object
 
- TBD