apidom-ls / apidom - Default to schema element for message payload when empty node

[frantuma]

@frantuma commented on Mon Jan 17 2022

Currently an "empty" payload is not parsed as schema element using refractorPluginReplaceEmptyElement as done for other empty elements. Goal of this ticket is applying the same mechanism also to payload.

Note. The possible reason for this behavior is payload type being any therefore admitting also non schema types.

asyncapi: '2.2.0'
components:
  messages:
    lightMeasured:
      payload:
        

[frantuma]

slightly related to #1075

[frantuma]

@char0n

#1113 replaces empty payload with asyncapi SchemaElement when a "compatible" schemaFormat is defined.

One thing to be possibly implemented (I'll add a PR) would be to default to SchemaElement also for "almost compatible" schema formats, specifically Json Schema Draft 07. While SchemaElement doesn't strictly represents 07 (it represents AsyncAPI Schema Object = Json Schema Draft 07 + vocabulary), for our purposes (completion in editor) it's ok to have SchemaElement also in this case.
Actually it would probably be good to have it replaced by SchemaElement (until we get a more thorough solution, see below) also for Json Schema 2020/12 and OpenAPI Schema object.
This can be done in separate plugin (as it's an opinionated/partial implementation), please let me know what you think.

The more complex discussion not in scope of this ticket involves nesting and extending namespaces, as well as parsing / deref them. Not sure if we have a ticket about this, in case we can create one and see from there

[char0n]

AsyncAPI Schema Object = Json Schema Draft 07 + vocabulary

This is only true in specific use-cases. The problem is that AsyncAPI Schema Object replaces every object containing $ref with Reference Object. JSON Schema Draft 07 does not, and dereferencing and resolution rules are completely different. I've aligned how I do wanna try to approach this problem in #1075 (comment). Let me know what you think.

[frantuma]

@char0n I agree and look forward for #1075 (comment), as it will address various areas. In scope of my previous comment, applying what mentioned in #1075 would probably address the above also.