bug: query parameter resolver issue

[lina2358]

Just discovered, that this belongs here: Apicurio/apicurio-studio#1240 (closing there)

[lina2358]

Found this which might temporarily alleviate: https://github.com/asyncapi/parser-go

If a document is valid, the parser provides dereferenced output

I wonder if it's a good idea, especially in sight of #168 (full JSON Schema compliance), to maintain an in-tree parser.

[EricWittmann]

Reading the bug from Apicurio/apicurio-studio#1240 I think the problem is that the Apicurio Studio editor does not yet support parameter references. The parser should handle it just fine, but the visual editor does not (yet). If there is something about the parser (here in data-models) that you think is broken please let me know.

As for the other comment, what do you mean by this?

maintain an in-tree parser.

[lina2358]

Apicurio Studio editor does not yet support parameter references

So I'm closing this and reopening the other. Maybe trivial: on apicurito, it also fails to show.

About in tree parser: I wondered if apicurio wouldn't be better off to use a dedicated parser library for json schemata.
(Or if there is non, even factoring this out?) In my past assumption that the issue is of the parser, interfacing with a broader user base brings about stability and completeness guarantees.

[EricWittmann]

Ah yes - this is an issue with AsyncAPI as well. Previous versions of OpenAPI defined its own customized variant of JSON Schema. As a result, we implemented that as part of the OpenAPI parser rather than trying to pull in another parser. However, AsyncAPI (and I think OpenAPI soon if not as part of the latest version) allows data types to be defined via different schema languages, not just JSON Schema. So that will require some sort of pluggable parser for the different schema languages that might be in use.

The challenge for us is that the Apicurio Data Models library is supported in both Java and Typescript/Javascript. That makes it much harder to pull in someone else's parser. This is done for good reason (we use the library in the browser and also server-side in our Java based applications).

I'm definitely open to suggestions in this area! :)

[lina2358]

I've read about the reasoning behind java/typescript and why it's done. Maybe the parser is (getting) good enough to carve it out and register it with https://json-schema.org/implementations.html#utilities (for both java & typescript)?

[EricWittmann]

That's a really good suggestion - we should break out the JSON Schema parsing the same way we do the other specs we support (several variants of OpenAPI and one current variant of AsyncAPI). Really formalize the JSON Schema model and parser and then register it. Good idea. I'll open a separate GH issue for this.

Eventually we may need to look at other formats as well, such as Avro (or any schema spec expressed using JSON/YAML).