Parse correctly schemas different to AsyncAPI schema

[Pakisan]

Specification can handle properties from OpenAPI schema, for example, but only when schemaFormat was provided

It's time to choose parsing strategy and bring OpenAPI schema, at least, to this repo to parse it correctly

Related issues:

• discriminator field #160
• Unable to parse a spec with an example attribute #163
• Unable to parse a spec with an nullable attribute #164

Available formats: Schema formats table
Reference: asyncapi/spec#1037

[jaydeepk]

@Pakisan, I went through the discussion in 1037.
I just want to clarify my understanding:
Would it be fair to assume that if we wish to use open api 3.0 attributes like 'nullable' and 'example', we need to specify the schemaFormat as 'application/vnd.oai.openapi;version=3.0.0'.

So would this be a valid asnyc api 2.6 spec:

messages:
    product:
      name: product
      title: An inventory product
      summary: Product representing items in inventory
      contentType: application/json
      payload:
        schemaFormat: application/vnd.oai.openapi;version=3.0.0
        type: object
        properties:
          name:
            description: Every product has a name
            type: string
          inventory:
            description: Count of items in inventory
            type: number
            nullable: true
          id:
            description: Unique identifier of the product
            type: number

[Pakisan]

@Pakisan, I went through the discussion in 1037.

I just want to clarify my understanding:

Would it be fair to assume that if we wish to use open api 3.0 attributes like 'nullable' and 'example', we need to specify the schemaFormat as 'application/vnd.oai.openapi;version=3.0.0'.

So would this be a valid asnyc api 2.6 spec:

messages:

    product:

      name: product

      title: An inventory product

      summary: Product representing items in inventory

      contentType: application/json

      payload:

        schemaFormat: application/vnd.oai.openapi;version=3.0.0

        type: object

        properties:

          name:

            description: Every product has a name

            type: string

          inventory:

            description: Count of items in inventory

            type: number

            nullable: true

          id:

            description: Unique identifier of the product

            type: number

Yes, you are right to use Avro, OpenAPI, ... schemas, user MUST provide schemaFormat to tell which parsing strategy to use

I added this issue to first RC release

[Pakisan]

Implemented in 1.0.0-RC