Reunite the meta-schemas

[gregsdennis]

For 2019-09, the meta-schema was split along the vocab boundaries, and each vocab got its own, and the top-level meta-schema simply referenced these individual ones.

With vocabs being put into the feature life cycle process as a proposal, it doesn't make sense to release the meta-schemas split this way.

Should we reunite them? I don't think that we need to, but the split doesn't really make sense outside of the vocabularies concept.

Our process says that a proposed keyword should be added to the meta-schema with a true value to define it for implementations. (Implementation need to "know about" it.) This would apply to $vocabulary as well. This means that we can leave the $vocabulary keyword in, and implementations that don't support the feature should just ignore it (because they have to "know about" proposal keywords, even if they don't support them).

To be more explicit, the core vocab schema would be updated to

{
  // ...
  "properties": {
    // ...
    "$vocabulary": true,
    // ...
  },
  // ...
}

and the (top-level) meta-schema would remain unchanged, still containing a $vocabulary keyword.

[jdesrosiers]

We certainly can leave it how it is and it would be fine. I think there are pros and cons either way. Leaving it how it is encourages people to implement the proposal which generates feedback. However, I think we have enough feedback to know that it needs a pretty major overhaul if not a complete replacement. So, encouraging implementation might not be productive.

Another perspective to consider is that we've seen several times people be confused about the meta-schema being in multiple parts. Reuniting them could make things easier for users.

Another perspective is that the united meta-schema will validate faster than the modular one.

My preference would be to reunite the meta-schema, but I don't feel very strongly about it. I think the only reason to keep them separated is if we expect we're just going to split them again exactly the way they were before. That would be unnecessary churn, but I don't think that's likely.