Add JSON Schemas for Driver and Layer Manifests

[charles-lunarg]

The JSON Schema format allows for automatic validation of a given manifest file. This enhances the ability for layer and driver developers to check that their manifest files are correct, as well as clarifying the exact format that the loader expects manifest files to be in.

These files will be available inside the repo for reference, but the primary location they will be made available from is:
https://schema.khornos.org/vulkan/

Each version of the Driver and Layer Manifest formats have their own schema, allowing verification of whichever version the driver or layer intends to use.

[ci-tester-lunarg]

CI Vulkan-Loader build queued with queue ID 20129.

[ci-tester-lunarg]

CI Vulkan-Loader build # 2122 running.

[ci-tester-lunarg]

CI Vulkan-Loader build # 2122 passed.

[christophe-lunarg]

Should that include the layer settings which already has a schema here https://github.com/LunarG/VulkanTools/blob/main/vkconfig_core/layers/layers_schema.json?

[charles-lunarg]

Should that include the layer settings which already has a schema here https://github.com/LunarG/VulkanTools/blob/main/vkconfig_core/layers/layers_schema.json?

So I am not against it, but it would be great if there was a way to define a 'common' base set of valid properties, so I am not having to duplicate the properties between the different manifest types (implicit, explicit, & meta).

[christophe-lunarg]

I don't know what you mean by a way to define a 'common' base of valid properties.

My suggestion is basically to add the "features", "status", "introduction", "url", "status" element to you JSON schema. Each of these can be define in the "definitions" section and reference in each manifest types.

I think the "features" element only concern implicit and explicit layer manifests.

I can push a commit for this if you want,

[charles-lunarg]

There are separate definitions for implicit, explicit, and meta layers. To add the `"features", "introduction" fields (the "url" and "status" fields are already present) would mean copy pasting them to the implicit, explicit, and meta layer definition.

The reason I was hesitant is that this PR is adding schemas for 'the same thing' that layers_schema.json defines, which causes confusion.

Probably the best course of action is to combine both schema's, since vkconfig and the loader need common elements in the manifest (as well as having elements that are only applicable to either). That shouldn't be too hard, the common bits are easy enough to combine (since they define the same things!) and the not-common parts can be taken wholesale. What that means for layers_manifest.json, I am not sure.

[christophe-lunarg]

I would be fine with just deleting layers_manifest.json once this is done.

`"features", "introduction" fields (the "url" and "status" fields are already present) would mean copy pasting them to the implicit, explicit, and meta layer definition.

This is confusing to me, it sounds like you imply you would have to copy the definision of each of these elements multiple times in each schema but we can define them once in schema schema and reference them for each layer manifest type.

[charles-lunarg]

This is confusing to me, it sounds like you imply you would have to copy the definision of each of these elements multiple times in each schema but we can define them once in schema schema and reference them for each layer manifest type.

I definitely am not keeping my thoughts straight. So you are definitely right about being able to have the definition once, then re-use that between the different layer types.

What I'm more annoyed with is having to copy the definitions into the schema for each version, when it should be defined in one place (common_layer_definition.json maybe) and referenced there. That would clean everything up massively, so I will pursue doing that with an update to this PR.