[json] schemas should be able to be validated starting at a given json property as the root

[baronfel]

While writing ASP.Net Core applications, you typically have an appsettings.json file which is used to collect any sort of runtime configuration. This file is very open in terms of schema, and typically different areas of concern in the application will have relatively well-structured config underneath a particular 'parent' key, which serves as a namespace. Take for example the Serilog logging library. It looks for configuration under the "Serilog" key in this file, at which point everything else follows a schema. It would be nice somehow to map this schema to the key particularly.

[aeschli]

Please add an example for an appsettings.json file.

Can you add a schema for appsettings.json like that ?

{
   type: 'object',
   properties: {
      'Serilog': { "$ref': 'https://gist.github.com/turchenkoalex/ff9dc8443c3002eccf8df58020f82339' }
   }
}

[baronfel]

That's hard to do because right now the appsetting.json file is a grab-bag, where any and all runtime settings (which can change based on which components/libraries you've added to your application) can live. There's a discussion about adding schema for the 'default' microsoft-provided properties at this issue though: dotnet/aspnetcore#2867.

While I could make a schema like that^ I think the larger question is how to do that and 'merge' the schemas if Microsoft ever did ship their official schema.

[aeschli]

• in VSCode if two (or more) schemas are contributed to the same file, we merge them (its an OR of all of them)
• but also single schema with all known library-schemas could be a solution. Why not suggesting the AspNetCore team that defines that schema to also accept to include associations for other libraries?
• Just in case, VSCode also allows dynamically created schemas as described here: [json] Allow users to register a json validator through code similarly to how they can register one through package.json #77433 (comment)
  So you can write an extension that looks at the used libraries and creates a merged schema.

[baronfel]

I didn't realize that multiple schemas were merged together! That covers most of the use case as far as I'm concerned then. Thank you for walking me through this.