Skip to content
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

Consider aligning context objectType enums with OAS spec. fragment-ids #17

Open
MikeRalphson opened this issue Oct 12, 2017 · 1 comment

Comments

@MikeRalphson
Copy link
Contributor

MikeRalphson commented Oct 12, 2017

I.e. in the example, OperationObject -> operationObject. The rationale for this is that fragment identifiers are case-sensitive. This would aid linking to the relevant area of the specifications.

It might also help those who want to produce (and keep up to date) a combined specification from the source OAS specification plus their extensions. Cf SmartAPI (ping @newgene).

An alternative would be to use the property names from the OpenAPI schemas (once an official 3.0.0 schema is settled upon), thus OperationObject -> operation for OASv2 or the gnostic 3.0 schema, -> Operation for webron's 3.0 schema. This wouldn't be my favoured option, as the schema may impose its own model (e.g. ParameterWithSchemaWithExample).

@blake-mealey
Copy link

Before I get into this too far, I wonder if this project has seen much work recently? Has there been much adoption of this? Are there any alternatives with more traction?

I came to the GH issues to post a comment around where the "OAS3ObjectTypeName enum" is defined, wondering if it was based on the fragment IDs in their docs. I like @MikeRalphson's suggestion of using the fragments. There also doesn't seem to be a "nice" list of object names with the associated metadata of whether or not extensions "may" be applied to them. In the spec, it's a bit awkward to get that info, although I suppose I could write a script to consolidate it.

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

No branches or pull requests

2 participants