Clarification on Reference/Schema

[char0n]

Hi everybody,

I'm working on AsyncApi 2.0.0 tooling and I'm seeking a verification of my understanding of the spec regarding Reference/Schema Objects.

Let's say I have following Schema Object definition somewhere inside AsyncApi 2.0.0 document.

{
  "type": "object",
  "oneOf": [
    { "$ref": "#/components/schemas/Schema1" }
   ]  
}

Semantics of this fragments are going to be following:

(SchemaObject
  (FixedField
    (String)
    (String))
  (FixedField
    (String)
    (Array
      (ReferenceObject))))   
)

When constructing semantics I've used the following sentence from the spec:

Alternatively, any time a Schema Object can be used, a Reference Object can be used in its place. This allows referencing definitions in place of defining them inline.

I understand it in the sense that whenever the SchemaObject is intercepted and that SchemaObject only contains $ref propertly, it is understood as ReferenceObject. JSON Reference spec is applied for dereferencing the Reference Objects. This also effectively means that $id on SchemaObject can be defined, but virtually have no semantics and is not used for dereferencing at all.

Am I correct in my understanding and assumptions?

Thanks a lot!

PS: just a suggestion, maybe enabling Discussions on this repo would be beneficial so that questions are directed there.

[jonaslagoni]

Hey @char0n, sounds awesome 👍 Feel free to join our Slack, we love to hear about the tooling you are making 😄

I understand it in the sense that whenever the SchemaObject is intercepted and that SchemaObject only contains $ref propertly, it is understood as ReferenceObject. JSON Reference spec is applied for dereferencing the Reference Objects.

Yes, that is correct.

This also effectively means that $id on SchemaObject can be defined, but virtually have no semantics and is not used for dereferencing at all.

I think this is incorrect, if I understand your point of view correctly.

In general, I think that this resource explains the answer to your question better than I can here. (we follow JSON Reference spec not JSON Schema spec for reference solving)

Let me know if the resource does not answer your question 🙂

PS: just a suggestion, maybe enabling Discussions on this repo would be beneficial so that questions are directed there.

Feel free to create a separate issue for this, it is a great suggestion 👍

[char0n]

Hi @jonaslagoni,

I think this is incorrect, if I understand your point of view correctly.
In general, I think that this resource explains the answer to your question better than I can here.

That's exactly my point and my un-clarity within specification. AsyncApi 2.0.0 claims:

The Reference Object is defined by JSON Reference and follows the same structure, behavior and rules
For this specification, reference resolution is done as defined by the JSON Reference specification and not by the JSON Schema specification.

If resolution complies with JSON Reference spec, and JSON Schema specification should be disregarded, the only logical conclusion I see is that $id has no semantic meaning during dereference (it's ignored as JSON Reference spec doesn't recognize it)

[jonaslagoni]

@char0n after reading up on a couple of different things, you are correct in your assumption that $id has no semantic meaning during dereference 🙂 and the example I provided are not correct for this as you said, since we follow JSON Reference spec.

[char0n]

@jonaslagoni cool, thank you for your clarifications and time!