nullable does not work ?

[ymarillet]

As defined in the specification, any Schema Object MAY have a "nullable" property, but I can't make it working in the editor, nor find it in the spec implementation (https://github.com/asyncapi/asyncapi/blob/master/schema/asyncapi.json)

Should it be removed from the doc ?

[fenollp]

Maybe the JSON schema version of "nullable": true works?
"type": ["null", ...]

[ymarillet]

The editor does not complain with type: ["null", string]

But it shouldn't work as per the specification:

The following properties are taken from the JSON Schema definition but their definitions were adjusted to the AsyncAPI Specification.

type - Value MUST be a string. Multiple types via an array are not supported.

[fmvilas]

Hi @ymarillet! Sorry for the late response. I'm currently on holidays and can't help so much but there are two issues here:

• As you correctly point out, it should be supporting nullable and should be complaining about [null, string].
• The reason you don't see it working is because the documentation generator is parsing the schemas as if they were jsonschema schemas instead of asyncapi schemas. And on top of that, I didn't take into account the possibility of having a nullable property.

Would you mind creating a PR on https://github.com/asyncapi/docgen?

[ymarillet]

Hello there

I don't have much time to work on this unfortunately :(, but will try to as soon as I get some spare time..

In the meantime, please do not consider I'm working on it activly.

I really like the project though, hope it'll get even better !

[fenollp]

Could these help?

• https://github.com/wework/json-schema-to-openapi-schema
• https://github.com/mikunn/openapi-schema-to-json-schema

I'd love a solution to this issue too!

Also, since AsyncAPI isn't OpenAPI why not just use a subset of JSON Schema Draft XY? OpenAPI schemas are not exactly a subset + history has shown people get confused between the two + there are way more JSON Schema validators/tools than there are for OpenAPI Schemas...

I can't wait for both these standards to support "here's my schema in language XYZ" :)

[fmvilas]

@fenollp I'm glad you ask for multiple schema support. It's already implemented in the spec for version 2.0.0, which should be ready by May this year. Check it out:

• [FEATURE REQUEST] Add support for multiple schema formats spec#113
• Separate operation from message and change schema format definition mechanism spec#158

[fenollp]

@fmvilas Nice! May isn’t far off too :)
We’re going to need to be able to specify schemas in more than one formats though at some point. It appears you’d prefer to allow as of yet unspec-ed Overlays instead of allowing multiple schema formats for the same payload. Why not. I guess there are issues I’m not seeing with the latter.
Anyway we may rely on something that translates for example our protobuf to JSON schema but these two have semantics that the other misses so I’m not sure about that yet.

[fmvilas]

We removed support for multiple formats on a single message for simplicity of the spec because that's not the case of many people. Overlays will allow you to do that. In any case, if the message is not exactly the same, they should be different messages.

[fmvilas]

This was fixed by #204. Closing.