Skip to content

updates for identification of spec, schema #631

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 2 commits into from
Apr 14, 2016
Merged

updates for identification of spec, schema #631

merged 2 commits into from
Apr 14, 2016

Conversation

fehguy
Copy link
Contributor

@fehguy fehguy commented Apr 8, 2016

Fixes #561

@fehguy
Copy link
Contributor Author

fehguy commented Apr 8, 2016

Also fixes #496

@@ -71,7 +71,7 @@ The schema exposes two types of fields. Fixed fields, which have a declared name

The OAS representation of the API is made of a single file. However, parts of the definitions can be split into separate files, at the discretion of the user. This is applicable for `$ref` fields in the specification as follows from the [JSON Schema](http://json-schema.org) definitions.

By convention, the OpenAPI Specification (OAS) file is named `swagger.json`.
By convention, the OpenAPI Specification (OAS) file is named `oas.json`.
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

or oas.yaml???

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

or openapi.yaml and openapi.json

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

openapi.json works for me :)

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I prefer openapi.* if we must suggest something, although I prefer if we didn't express a preference for a filename.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Another vote for openapi.*.

@fehguy
Copy link
Contributor Author

fehguy commented Apr 8, 2016

Schema version + spec version will not necessarily be the same.

@OAI/tdc to review by Weds and provide comments?

@@ -106,7 +106,8 @@ This is the root document object for the API specification. It combines what pre

Field Name | Type | Description
---|:---:|---
<a name="oasSwagger"></a>swagger | `string` | **Required.** Specifies the OpenAPI Specification version being used. It can be used by the Swagger UI and other clients to interpret the API listing. The value MUST be `"2.0"`.
<a name="oasSwagger"></a>swagger | `string` | **Required.** Specifies the OpenAPI Specification version being used. It can be used by tooling vendors and clients to interpret the version. The structure shall be `major`.`minor`.`patch`, where `patch` versions _must_ be compatible with the existing `major`.`minor` tooling. Typically patch versions will be introduced to address errors in the documentation, and tooling should typically be compatible with the corresponding `major`.`minor` (3.0.*). Patch versions will correspond to patches of this document.
<a name="oasSchema"></a>schema | `string` | An optional URL to a formal OAS schema. If present, tooling _may_ choose to use this for validating the document, and the location _must_ be a formally approved OAS schema produced by the OpenAPI working group.
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Kill this, will cause more harm than good @OAI/tdc

Will publish a formal location of the schema (https://openapis.org/schemas/3.0-latest.json)

@webron
Copy link
Member

webron commented Apr 10, 2016

Regarding the version - reiterating what we discussed (for documentation sake) - the benefits of a patch-level version granularity are clear, but we're also not going to be update the spec (normally) for every minor change. We'll do our best to collect changes and not have a too-frequent release cycle.

@webron
Copy link
Member

webron commented Apr 10, 2016

Other than that, 👍 from me for the PR (assuming suggested file name and removal of schema).

@fehguy
Copy link
Contributor Author

fehguy commented Apr 11, 2016

I have removed the schema reference and swagger from the key name.

@fehguy
Copy link
Contributor Author

fehguy commented Apr 11, 2016

@OAI/tdc please approve or reject

@darrelmiller
Copy link
Member

👍

2 similar comments
@jharmn
Copy link
Contributor

jharmn commented Apr 13, 2016

👍

@earth2marsh
Copy link
Member

👍

@fehguy fehguy merged commit 55bff58 into OpenAPI.next Apr 14, 2016
@fehguy fehguy deleted the issue-561 branch October 20, 2016 17:12
handrews added a commit to handrews/OpenAPI-Specification that referenced this pull request Oct 11, 2024
updates for identification of spec, schema

[Manually ported merge commit]

Co-authored-by: Tony Tam <tony@eatbacon.org>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants