Allow different bundling technique for schemas below draft 2019-09

[jonaslagoni]

Because the compound schema and bundling behavior was not finalized until draft 2019-09 it's not really possible to dictate behavior and instead I will suggest leaving it up to the user which technique to use.

The two I see are:

1. The main default one, compound schema as is.
2. Absolute references to definitions instead of keeping the old references

I know there are arguments to be made that reference libraries SHOULD be able to understand the compound schemas, reality is that we are going to be with a leg in each camp until the tools mature, and until then, options 2 will make it possible to all tools to understand the schemas because it's the basic premise they operate on.

For context, we encountered this problem with vscode asyncapi/spec-json-schemas#247 and we have to adapt the bundling of the AsyncAPI schema files. The best scenario would be to enable this on a library level instead of us having to build our own custom solution.

cc @derberg

[jdesrosiers]

Although bundling wasn't mentioned in the spec until 2019-09, the mechanism it uses has existed since draft-03. The problem isn't that VSCode hasn't gotten around to supporting bundling yet. The problem is that VSCode has a bug. It doesn't make sense for me to implement workarounds for every implementation that won't fix their bugs, even if it is VSCode.

But even if I did want to work around VSCode's bugs, there are problems with your proposal that make it a no-go. It's not as easy as just rewriting external references. If you don't bundle using $id (or ignore $id), you change how those bundled schemas behave. You have to not just rewrite the external reference, you have to rewrite every reference in the referred to schema. You also have to deal with conflicts in $anchors in any of the schemas being bundled. These are much more complex problems to solve than this implementation is designed to deal with. It couldn't be a simple config option. I'd have to reimplement with a different approach. In fact, the whole reason I wrote this implementation in the first place was to show that it's unnecessary to solve those problems.

I sympathize with your problem and I understand why AsyncAPI would want to be able to work around VSCode's bugs, but it doesn't make sense for this library to do that even if there was a way I could feasibly provide what you need. I'll be looking into filing an bug report with VSCode if there isn't one already.

[jonaslagoni]

My only point here is that absolute references, are supported by all libraries (that support very basic references of course) right out the gate, whereas compound schemas will only work in some libraries.

I bet you know some edge cases with JSON Schema references I don't know about, so I don't doubt that there will be 😄 And regarding the architecture of this library, well, I can't speak to the complexity this would create.

Thanks for the quick feedback 👍

[jdesrosiers]

compound schemas will only work in some libraries

That's not true. This has been required functionality since draft-03. It's not new or optional. There are always a few outliers that choose not to fix their known bugs, but this works properly in the vast majority of implementations.