In the documentation at docs/public/concepts/catalogs.md, some of the examples list an "id" and others list a "catalogId" at the top level of the JSON document.
We should be consistent on this.
id is used by JSON schema. But we specify catalogId in our specification, to ensure that its clear. Technically, both should be included and be valid, though I believe our SDKs on check the catalogId. I think the basic catalog sets both fields.
We should verify that all of the above is true, and make the examples set both, to match the basic catalog. The specification for v0.9, v0.9.1 and v0.10 should make it clear that both should be set. Later, we will migrate away from using JSON schema documents to represent catalogs, which would remove this weird requirement.
In the documentation at docs/public/concepts/catalogs.md, some of the examples list an "id" and others list a "catalogId" at the top level of the JSON document.
We should be consistent on this.
id is used by JSON schema. But we specify catalogId in our specification, to ensure that its clear. Technically, both should be included and be valid, though I believe our SDKs on check the
catalogId. I think the basic catalog sets both fields.We should verify that all of the above is true, and make the examples set both, to match the basic catalog. The specification for v0.9, v0.9.1 and v0.10 should make it clear that both should be set. Later, we will migrate away from using JSON schema documents to represent catalogs, which would remove this weird requirement.