Over chat Yoann Rodière asked if the VALIDATE option should deal with the fact that users might have extended the schema we expect.

I'd be happy to tackle this in an incremental way: start with the simplest possible validation (check that the schema is identical to the one we'd generate) and then improve from there, especially as I'm afraid it would take quite some experience and several iterations to define exactly what kind of extensions are valid.

Some simple validation leniency which we could consider in a first iteration, if it's not too complex:

• ignore types which we don't know about
• ignore fields which we don't need
• ignore analyzer definitions we don't use

For Field options such as indexable, stored, store-norms, etc.. we'd need to define a comparison scale for each option, to see if the option used by the server is at least as powerful as we expect.
Example: if we don't need norms, it's ok if the server enables norms. If we need the field to be stored, it's not ok if the option is not enabled on the server.

I'm totally fine to capture these in a follow up JIRA, as long as we document the limitations of our first version.