Merge main branch

darrelmiller · darrelmiller · commit b816307cdca3 · 2017-06-16T11:40:30.000-04:00
diff --git a/DEVELOPMENT.md b/DEVELOPMENT.md
@@ -1,51 +1,51 @@
 ## Development Guidelines
 
-This document intends to establish guidelines which build a transparent, open mechanism for deciding how to evolve the OpenAPI Specification. The Open API Technical Contributor Board will initially follow these processes when merging changes from external contributors or from the TCB itself. This guideline document will be adjusted as it makes sense.
+This document intends to establish guidelines which build a transparent, open mechanism for deciding how to evolve the OpenAPI Specification. The Open API Technical Contributor Board will initially follow these processes when merging changes from external contributors or from the TCB itself. This guideline document will be adjusted as practicality dictates.
 
 ## OAI Specification Driving factors
 
-The OpenAPI Specification should be use-case driven.  We can write support for hypothetical use cases as we see fit, but they should be backed by realistic scenarios
+The OpenAPI Specification should be use-case driven.  We can specify support for hypothetical use cases as we see fit, but specifications should be backed by realistic scenarios.
 
 ## Specification Change Criteria
 
-The specification _will change_ from the original 2.0 version.  We should typically do so when any of the following criteria are met:
+The specification _will change_ from the original 2.0 version.  We should typically make changes when any of the following criteria are met:
 
- - Clarity.  The current "way" something is done doesn't make sense, is complicated, or not clear
- - Consistency.  A portion of the specification is not consistent with the rest, or the industry standard terminology
- - Necessary functionality.  We are missing functionality because of a certain design of the specification
- - Forward-looking designs.  As usage of APIs evolves to new protocols, formats, patterns, we should always be considering what the next important functionality should be
+ - Clarity.  The current "way" something is done doesn't make sense, is complicated, or not clear.
+ - Consistency.  A portion of the specification is not consistent with the rest, or with the industry standard terminology.
+ - Necessary functionality.  We are missing functionality because of a certain design of the specification.
+ - Forward-looking designs.  As usage of APIs evolves to new protocols, formats, and patterns, we should always consider what the next important functionality should be.
  - Impact.  A change will provide impact on a large number of use cases.  We should not be forced to accommodate every use case.  We should strive to make the _common_ and _important_ use cases both well supported and common in the definition of the OAI Spec.  We cannot be edge-case driven.
 
 
 ## Tracking Process
 
- - Use GitHub for all spec designs, use cases, etc.
+ - Use GitHub for all spec designs, use cases, and so on.
  - As with 2.0, the **human readable** document is the source of truth.  If using a JSON Schema again to document the spec, it is secondary to the human documentation.  The documentation should live in a *.md file, in parallel to the 2.0 document (versions/3.0.md for example).
- - The `master` branch shall remain the current, released OpenAPI Specification (i.e. 2.0).  We will work in an OpenAPI.next branch, which shall be described and linked to on the **default** README.md on master
- - Examples of how something is described _currently_ vs. the proposed solution should accompany any change proposal
- - New features should be done in feature branches which, upon approval, be merged into the OpenAPI.next branch.
- - Use labels for the workflow of specification changes.  For example, this may be labeled as `proposed`, `needs migration review`, `needs tooling review`, `needs documentation`, `rejected`, `needs approval`.  These labels must be assigned by project committers
- - An issue will be opened for each feature change.  Embedded in the issue OR ideally linked in a file via pull-request (PR), a document should be supplied for use cases for the change
- - A PR will be used to describe the _proposed_ solution, and linked to the original issue
- - Not all committers will contribute to every single proposed change.  There may be many open proposals at once, and multiple efforts may happen in parallel
+ - The `master` branch shall remain the current, released OpenAPI Specification (i.e., 2.0).  We will work in an OpenAPI.next branch, which shall be described and linked to on the **default** README.md on master.
+ - Examples of how something is described _currently_ vs. the proposed solution should accompany any change proposal.
+ - New features should be done in feature branches which, upon approval, are merged into the OpenAPI.next branch.
+ - Use labels for the workflow of specification changes.  Examples of labels are `proposed`, `needs migration review`, `needs tooling review`, `needs documentation`, `rejected`, and `needs approval`.  These labels must be assigned by project committers.
+ - An issue will be opened for each feature change.  Embedded in the issue, or ideally linked in a file via pull-request (PR), a document about use cases should be supplied with the change.
+ - A PR will be used to describe the _proposed_ solution, and linked to the original issue.
+ - Not all committers will contribute to every single proposed change.  There may be many open proposals at once, and multiple efforts may happen in parallel.
  - When the OpenApi.next spec is complete and approved for release, the branch will be merged to master.
 
 ## Approving Changes
 
 For each change in the specification we should _always_ consider the following:
 
  - Migration.  Is this a construct that has a path from the existing 2.0 specification?  If so, how complicated is it to migrate to the proposed change?
- - Tooling.  Strive to support code generation, software interfaces, spec generation techniques.  Some features may be impossible to support in different frameworks/languages.  These should be documented and considered if the change should be approved.
- - Visualization.  Can the specification change be graphically visualized somehow in a UI or other?
+ - Tooling.  Strive to support code generation, software interfaces, and spec generation techniques.  Some features may be impossible to support in different frameworks/languages.  These should be documented and considered during the change approval process.
+ - Visualization.  Can the specification change be graphically visualized somehow in a UI or other interface?
 
-Spec changes should be approved by a majority of the committers.  This can be done by commenting on the issue itself ("Approved by @fehguy" for example).  Once voting criteria is met, any committer can merge the PR. (**TODO: we will want to formalize what voting criteria actually is).
+Spec changes should be approved by a majority of the committers.  Approval can be given by commenting on the issue itself, for example, "Approved by @fehguy".  After voting criteria is met, any committer can merge the PR. (**TODO**: we will want to formalize what voting criteria actually is).
 
 No change should be approved until there is documentation for it, supplied in an accompanying PR.
 
 ## Transparency
 
-We should always be as transparent as possible.  Sometimes there will be discussions that use customer names, sensitive use cases, etc.  These must be anonymized, discussed in a private repository, or offline
+We should always be as transparent as possible.  Sometimes there will be discussions that use customer names, sensitive use cases, and so on.  These must be anonymized, discussed in a private repository, or conducted offline.
 
- - Asynchronous discussions should live in the GitHub issues for this project
- - Realtime discussions should be in a public chat such as IRC or Slack
+ - Asynchronous discussions should live in the GitHub issues for this project.
+ - Realtime discussions should be in a public chat such as IRC or Slack.
 
diff --git a/IMPLEMENTATIONS.md b/IMPLEMENTATIONS.md
@@ -1,10 +1,9 @@
 ### Implementations
 
-Below is a list of known tooling implementing the 3.0.0 specification. Because
-the 3.0.0 specification has not yet been released, please consult the details of
-any projects listed below for notes about stability and roadmap.  The process 
+Below is a list of known tooling that implements the 3.0.0 specification. Because
+the 3.0.0 specification has not yet been released, refer to the details of projects listed below for any notes about stability and roadmap.  The process 
 to create the best possible 3.0.0 specification includes feedback from end-users
-and tooling creators alike, and it is strongly encouraged that draft tooling be
+and tooling creators. We strongly encourage draft tooling be
 made available for early users of the OAS.
 
 These tools are not necessarily endorsed by the OAI.
@@ -25,7 +24,7 @@ These tools are not necessarily endorsed by the OAI.
 
 | Title          | Project Link | Language |Description                          |
 |----------------|--------------|----------|---------------------|
-| openapi-viewer | [GitHub/koumoul/openapi-viewer](https://github.com/koumoul-dev/openapi-viewer) | Vue.js | Browse and test a REST API described with the OpenAPI 3.0 Specification |
+| openapi-viewer | [GitHub/koumoul/openapi-viewer](https://github.com/koumoul-dev/openapi-viewer) | Vue.js | Browse and test a REST API described with the OpenAPI 3.0 Specification. |
 
 
 #### Server Implementations
@@ -35,5 +34,5 @@ These tools are not necessarily endorsed by the OAI.
 
 | Title          | Project Link | Language |Description                          |
 |----------------|--------------|----------|---------------------|
-| baucis-openapi3 | [Github/metadevpro/baucis-openapi3](https://github.com/metadevpro/baucis-openapi3) | Node.js | [Baucis.js](https://github.com/wprl/baucis) plugin for generating OpenAPI 3.0 compliant API contracts |
-| Google Gnostic | [GitHub/googleapis/gnostic](https://github.com/googleapis/gnostic) | Go | Compile OpenAPI descriptions into equivalent Protocol Buffer representations |
+| baucis-openapi3 | [Github/metadevpro/baucis-openapi3](https://github.com/metadevpro/baucis-openapi3) | Node.js | [Baucis.js](https://github.com/wprl/baucis) plugin for generating OpenAPI 3.0 compliant API contracts. |
+| Google Gnostic | [GitHub/googleapis/gnostic](https://github.com/googleapis/gnostic) | Go | Compile OpenAPI descriptions into equivalent Protocol Buffer representations. |
diff --git a/README.md b/README.md
@@ -6,22 +6,22 @@
 
 This is the working branch for the next version of the OpenAPI Specification. You can read more about the Open API Initiative (OAI) at [https://openapis.org](https://openapis.org).
 
-The current, released version of the OpenAPI Specification is 2.0, through donation of the Swagger Specification to the OAI by SmartBear Software.  If you are interested in the release specification, please see the [master branch](https://github.com/OAI/OpenAPI-Specification/blob/master/README.md) of this project.
+The current, released version of the OpenAPI Specification is 2.0, through donation of the Swagger Specification to the OAI by SmartBear Software.  If you are interested in the release specification, see the [master branch](https://github.com/OAI/OpenAPI-Specification/blob/master/README.md) of this project.
 
-Development of the next version of the OpenAPI Specification is being guided by the [OAI Technical Contributors Board](https://github.com/OAI/OpenAPI-Specification/blob/OpenAPI.next/CONTRIBUTORS.md).  This group of committers will be bring their API expertise, incorporating feedback from the community, and expanding the group of committers as appropriate.  All development activity on the future specification will be performed as features and merged into this branch.  Upon release of the OpenAPI Specification, this branch will be merged to master.
+Development of the next version of the OpenAPI Specification is guided by the [OAI Technical Contributors Board](https://github.com/OAI/OpenAPI-Specification/blob/OpenAPI.next/CONTRIBUTORS.md).  This group of committers bring their API expertise, incorporate feedback from the community, and expand the group of committers as appropriate.  All development activity on the future specification will be performed as features and merged into this branch.  Upon release of the OpenAPI Specification, this branch will be merged to master.
 
-You can see the current process for development inside the OpenAPI Specification [here](https://github.com/OAI/OpenAPI-Specification/blob/OpenAPI.next/DEVELOPMENT.md).
+The current process for development of the OpenAPI Specification is described in [Development Guidelines](https://github.com/OAI/OpenAPI-Specification/blob/OpenAPI.next/DEVELOPMENT.md).
 
 ## Participation
 
-The OpenAPI Specification is a community driven, open project hosted by the Linux Foundation. The OAI encourages participation from individuals and companies alike. If you wish to participate in the evolution of the OpenAPI Specification, please consider the following:
+The OpenAPI Specification is a community driven, open project hosted by the Linux Foundation. The OAI encourages participation from individuals and companies alike. If you want to participate in the evolution of the OpenAPI Specification, consider taking the following actions:
 
 * Review the [current specification](https://github.com/OAI/OpenAPI-Specification/blob/OpenAPI.next/versions/3.0.md). The human-readable markdown file _is the source of truth_ for the specification.
-* Review the [development](https://github.com/OAI/OpenAPI-Specification/blob/OpenAPI.next/DEVELOPMENT.md) process so it's clear how the spec is evolving.
+* Review the [development](https://github.com/OAI/OpenAPI-Specification/blob/OpenAPI.next/DEVELOPMENT.md) process so you understand how the spec is evolving.
 * Check the [issues](https://github.com/OAI/OpenAPI-Specification/issues) and [pull requests](https://github.com/OAI/OpenAPI-Specification/pulls) to see if someone has already documented your idea or feedback on the specification. You can follow an existing conversation by adding a comment to the existing issue or PR.
-* Create an issue to describe a new concern along with, if possible, a proposed solution.
+* Create an issue to describe a new concern. If possible, propose a solution.
 
-Be aware that not all feedback can be accommodated and there may be solid arguments to/from a change being appropriate for the specification.
+Not all feedback can be accommodated and there may be solid arguments for or against a change being appropriate for the specification.
 
 ## License
 
diff --git a/examples/v3.0/callback-example.yaml b/examples/v3.0/callback-example.yaml
@@ -0,0 +1,56 @@
+paths:
+  /streams:
+    post:
+      description: subscribes a client to receive out-of-band data
+      parameters:
+        - name: callbackUrl
+          in: query
+          required: true
+          description: |
+            the location where data will be sent.  Must be network accessible
+            by the source server
+          schema:
+            type: string
+            format: uri
+            example: https://tonys-server.com
+      responses:
+        '201':
+          description: subscription successfully created
+          content:
+            application/json:
+              schema:
+                description: subscription information
+                required:
+                  - subscriptionId
+                properties:
+                  subscriptionId:
+                    description: this unique identifier allows management of the subscription
+                    type: string
+                    example: 2531329f-fb09-4ef7-887e-84e648214436
+      callbacks:
+        # the name `onData` is a convenience locator
+        onData:
+          # when data is sent, it will be sent to the `callbackUrl` provided
+          # when making the subscription PLUS the suffix `/data`
+          $request.query.callbackUrl/data:
+            post:
+              requestBody:
+                description: subscription payload
+                content:
+                  application/json:
+                    schema:
+                      properties:
+                        timestamp:
+                          type: string
+                          format: date-time
+                        userData:
+                          $ref: '#/components/schemas/UserLogData'
+              responses:
+                '202':
+                  description: |
+                    Your server implementation should return this HTTP status code
+                    if the data was received successfully
+                '204':
+                  description: |
+                    Your server should return this HTTP status code if no longer interested
+                    in further updates
diff --git a/examples/v3.0/uber.yaml b/examples/v3.0/uber.yaml
@@ -289,8 +289,7 @@ components:
     Error:
       properties:
         code:
-          type: integer
-          format: int32
+          type: string
         message:
           type: string
         fields:
diff --git a/versions/3.0.md b/versions/3.0.md
