TAPRegExt silent schema update?

[Mark Taylor]

Markus and TCG,

from a pragmatic point of view, this silent update sounds pretty
reasonable under the circumstances, so if nobody has any technical
objections then personally I'd support whatever rule-bending is
required to get it done.

However I have a quibble.  The updated XSD you mention
(https://volute.g-vo.org/svn/trunk/projects/registry/TAPRegExt/TAPRegExt-v1.0.xsd)
contains some minor but non-essential rewording and reformatting
compared to http://www.ivoa.net/xml/TAPRegExt/TAPRegExt-v1.0.xsd.
If a silent update is done, I think the updated version should be
as close to the original published xsd as possible, though including
a comment near the top explaining the change, when it happened
and with what authorization.  I'd like a diff to look as clean
and comprehensible as possible.  The XSD to be updated should
therefore undergo some tidying first (and I'd like to eyeball the
diff to make sure that the change really is as minor as Markus claims).

(One other minor point: the document
https://volute.g-vo.org/svn/trunk/projects/registry/tapregext-erratum1
you mention looks like a 404 to me, though the other source
http://docs.g-vo.org/TREErr1.pdf seems clear enough, so it doesn't
really matter.)

If this silent change is agreed, I will make the corresponding
changes in taplint (which currently issues a Warning, though not
an Error, if non-IdentifierURIs are contained in DataModel/@ivo-id).

Mark

On Mon, 25 Jul 2016, Markus Demleitner wrote:

> Dear Collagues,
> 
> A fairly long while ago, I posted erratum drafts for TAPRegExt that
> would make dataModelURI xs:anyURI rather than vs: StandardID, which
> in turn is necessary unless we want a new registry record for every
> version of standards defining TAP data models (e.g.,
> http://docs.g-vo.org/TREErr1.pdf from Nov 2014, but that's already a
> digested form; see also
> https://volute.g-vo.org/svn/trunk/projects/registry/tapregext-erratum1
> for the source).
> 
> Unfortunately, the IVOA still doesn't have an Erratum process.  I had
> hoped that this thing could wait until we have TAPRegExt 1.1, but
> that's pending TAP 1.1 proceedings (as it should, since we may find
> out we need additional elements in there), while we now *really* need
> that minor schema update.  There are new publishing registries that
> need to be validated and have TAP services with data models like RR
> or EPN-TAP in them that have new-style identifiers, and Obscore 1.1
> will also have a new-style id.
> 
> So, things get urgent.  Lacking an Erratum process, I'd like to apply
> for an emergency procedure.  In this special case, where nobody
> has ever said anything against the proposed change although it has
> been the subject of several reviews (including the WG review of
> TAPRegExt 1.1): Can't we just go ahead and upload the updated schema
> file?  It's been available for quite a while from 
> https://volute.g-vo.org/svn/trunk/projects/registry/TAPRegExt/TAPRegExt-v1.0.xsd,
> and it's been in use for validation from within DaCHS for a long
> time, too.
> 
> The relaxation of tr:dataModel from vr:StandardID to xs:anyURI is
> really trivial, will never break anything, and is overdue ever since
> RegTAP passed (Dec 8 2014).  And it seems it cannot wait until we get
> a proper Errata process.
> 
> So: Does anyone from either the Registry WG or the TCG seriously
> object to just silently updating the schema file in the document
> repository and in the RofR validator?  I'd be happy to defend this in
> front of the Exec any time.  And could, perhaps, the TCG chair say
> that in this special situation that update is ok?  As I said, this is
> becoming operationally problematic.
> 
> Thanks,
> 
>           Markus
> 
> 

--
Mark Taylor   Astronomical Programmer   Physics, Bristol University, UK
m.b.taylor at bris.ac.uk +44-117-9288776  http://www.star.bris.ac.uk/~mbt/