Incomplete OAS modeling

[ghostbody]

openapi-core is a great repo as I am going to write a schema parse based on OAS 3.0.2.

I some modeling work which is done in openapi_core/schema as well as openapi_core/extensions. But the modeling work is relatively incomplete to OAS 3.0.2 specification.

For example:

openapi_core/schema/infos/models.py

class Info(object):

    def __init__(self, title, version):
        self.title = title
        self.version = version

However, in OAS 3.0.2 Specification:

https://github.com/OAI/OpenAPI-Specification/blob/master/versions/3.0.0.md#infoObject

Field Name	Type	Description
title	string	REQUIRED. The title of the application.
description	string	A short description of the application. CommonMark syntax MAY be used for rich text representation.
termsOfService	string	A URL to the Terms of Service for the API. MUST be in the format of a URL.
contact	Contact Object	The contact information for the exposed API.
license	License Object	The license information for the exposed API.
version	string	REQUIRED. The version of the OpenAPI document (which is distinct from the OpenAPI Specification version or the API implementation version).

description, termsOfService, license, description fields are missing.

I think it's necessary to compelete thess model definitions. When I am implementing my parse for some integrated framework (i.e. sandman2), it's very hard to use a big dictionary to describe the api specification. I need something like a specification builder.

spec = Spec()
spec.info = Info(title='some title', description='some description', version='0.0.1')
spec.servers = [
  Server(url='some url', title='some title'),
  Server(url='some url2', title='some title2')
]

spec.components.define_schema(
    'some_schema',
    Schema(...)
)

spec.components.define_schema(
   'another_schema',
   some_parser.parse(some_model_may_be_sqlalchemy)    # A function that returns a Schema Object is better than a dict!
)

spec.paths.register_custom_path(...)   # some customized path regsiter as long as the fucntion returns a Path Model Object 

If you think this is a decent idea, I will be glad to help with PRs, as well as soem needed documentation work.

[p1c2u]

Hi @ghostbody
it shouldn't be hard to add these fields. If you have spec dict you can use SpecFactory to parse it.