Schema versioning with errata

[Markus Demleitner]

Hi Brian,

On Fri, May 31, 2019 at 11:13:16AM -0700, Brian Major wrote:
> > Here's what I've done and how I propose to go on:
> >
> > (a) I changed the version attribute on the root of the schema file to
> >     "1.1+Erratum-1"
> 
> ...
> 
> >
> > Here's my reasoning:
> >
> > (a) is because people should be able to work out the "patchlevel" of
> > the schema.  When Erratum-3 is being applied, the version would
> > be 1.1+Erratum-1+Erratum-3.  Yes, that could potentially get long,
> > but since not many people will have too look at it, that's probably
> > acceptable.
> >
> 
> Hmm, would we ever have a XSD posted that did not take into account
> accepted errata?  If we did then I'd probably consider it a mistake made by
> the working group.

Well, first off, many errata do not influence the schema at all.  If
the schema doesn't change, /@version IMHO shouldn't change at all.

As a practical example, checkout the VOTable 1.3 errata,
https://wiki.ivoa.net/twiki/bin/view/IVOA/VOTable-1_3-Errata .
Erratum-1 doesn't change the schema, Erratum-2 does, Erratum-3
doesn't.  So, the current /@version of the schema *would* be
1.3+Erratum-2 (if VOTable followed this proposal).  If the next
erratum changes the schema, its version would be
1.3+Erratum-2+Erratum-4, otherwise it would stay (until perhaps
1.3+Erratum-2+Erratum-5).

Also, it is altogether possible that errata get rejected and/or
withdrawn, or they are approved in a different sequence than the one
in which they were handed in.  So, I think there's no way around
explicitly enumerating the errata reflected in the file.

         -- Markus

(who suddenly wonders if this actually a reply to your remark.  If it
isn't, apologies, and could you try making me see your point again?)