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

[MikeRalphson]

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]

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.