<div dir="ltr"><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">If the xsd is in version control and gets merged I don't think out-of-order errata changes will be lost. Of course, pending errata changes should remain in a branch (or pull request if github) until accepted, then merged. The xsd on <a href="http://www.ivoa.net">www.ivoa.net</a> should always come from the VC system, not from an upload by an arbitrary participant. We could make that a "process" but in reality the WG chair/vice-chair should probably be the ones pulling the trigger on VC -> web site and that should suffice.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">my 2c,</div><div class="gmail_default" style="font-size:small"><br clear="all"></div><div><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><div>--<br></div><div>Patrick Dowler<br></div>Canadian Astronomy Data Centre<br></div>Victoria, BC, Canada<br></div></div></div></div></div><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, 5 Jun 2019 at 02:45, Markus Demleitner <<a href="mailto:msdemlei@ari.uni-heidelberg.de">msdemlei@ari.uni-heidelberg.de</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi Brian,<br>
<br>
On Mon, Jun 03, 2019 at 12:16:40PM -0700, Brian Major wrote:<br>
> I'm guess I'm wondering what the use cases are for determining the 'patch<br>
> level' of a schema. A common pattern would be something like:<br>
<br>
Oh, I think the one main use case is: it lets errata authors and the<br>
document coordinator figure out if what's in the schema repo matches<br>
their expectations without having to look at the concrete changes of<br>
the errata and whether they are in the schema they see.<br>
<br>
The situation I'd like to be able to detect is, in a nutshell:<br>
<br>
(1) Alice starts Erratum-m and fixes her local copy of the schema <br>
accordingly<br>
(2) Bob uploads the Erratum-n changed schema<br>
(3) After Erratum-m is accepted, Alice uploads *her* version of the<br>
Erratum-m changes -- which by construction is still missing changes <br>
from Erratum-n.<br>
<br>
In effect, as far as the schema is concerned, Erratum-n is rolled<br>
back.<br>
<br>
Having these little tags in the (otherwise essentially unused)<br>
/@version of the schema would raise the likelihood we (mostly, the<br>
document coordinator) has a fair chance of catching such a mishap<br>
significantly (I'd say).<br>
<br>
> - someone builds an implementation against a schema for some version of a<br>
> standard<br>
> - an error is discovered which affects the schema so an erratum is<br>
> published and the schema file updated<br>
> - the implementor notices the erratum (which says it has affects on the<br>
> schema) so, to fix the implementation, he/she acquires the updated schema<br>
> file.<br>
<br>
Yes, that's another scenario. Essentially, again: "Catching version<br>
skews".<br>
<br>
Thanks,<br>
<br>
Markus<br>
</blockquote></div>