Schema versioning with errata

[Markus Demleitner]

Hi Brian,

On Mon, Jun 03, 2019 at 12:16:40PM -0700, Brian Major wrote:
> I'm guess I'm wondering what the use cases are for determining the 'patch
> level' of a schema.  A common pattern would be something like:

Oh, I think the one main use case is: it lets errata authors and the
document coordinator figure out if what's in the schema repo matches
their expectations without having to look at the concrete changes of
the errata and whether they are in the schema they see.

The situation I'd like to be able to detect is, in a nutshell:

(1) Alice starts Erratum-m and fixes her local copy of the schema 
    accordingly
(2) Bob uploads the Erratum-n changed schema
(3) After Erratum-m is accepted, Alice uploads *her* version of the
    Erratum-m changes -- which by construction is still missing changes 
    from Erratum-n.

In effect, as far as the schema is concerned, Erratum-n is rolled
back.

Having these little tags in the (otherwise essentially unused)
/@version of the schema would raise the likelihood we (mostly, the
document coordinator) has a fair chance of catching such a mishap
significantly (I'd say).

> - someone builds an implementation against a schema for some version of a
> standard
> - an error is discovered which affects the schema so an erratum is
> published and the schema file updated
> - the implementor notices the erratum (which says it has affects on the
> schema) so, to fix the implementation, he/she acquires the updated schema
> file.

Yes, that's another scenario.  Essentially, again: "Catching version
skews".

Thanks,

         Markus