VOResource 1.1 namespace implementations breaking XSD validity

[Theresa Dower]

Aha, thank you Juan for catching this, and to Markus for the quick follow-up.


I've fixed the stray MAST resource at our publishing registry end, hopefully as noted the VizieR update resolves the bulk of the issues.


Cheers,

--Theresa

________________________________
From: registry-bounces at ivoa.net <registry-bounces at ivoa.net> on behalf of Markus Demleitner <msdemlei at ari.uni-heidelberg.de>
Sent: Wednesday, February 3, 2021 3:47:36 AM
To: registry at ivoa.net
Subject: Re: VOResource 1.1 namespace implementations breaking XSD validity

External Email - Use Caution

Juan,

On Tue, Feb 02, 2021 at 04:24:56PM +0100, Juan Gonzalez wrote:
> Performing a compliance check we have found out that that ~85% of
> the VOResources currently published in the IVOA ecosystem are using
> the following namespace:
>
> xmlns:vr="http://www.ivoa.net/xml/VOResource/v1.1"

Ouch.  Yeah, that's bugs (which fortunately didn't hit at least my
RegTAP services because of fortunate conincidences).

> So in our understanding,
> xmlns:vg="http://www.ivoa.net/xml/VORegistry/v1.0" would have to be
> used to not break XSD validity.

That is right.

> This seems to be more on our responsibility as Registry providers
> to check resources validity. Would there be general consensus to
> request our publishing registries to perform this change?

Sure: Dear registry operators, please make it a routine to run your
registries through the validator at the beginning of each month.

However, this particular problem doesn't concern too many operators.
VizieR, where most of this comes from, will have a shiny new
publishing registry real soon now (cf. the talk at the last interop),
so that problem is going to go away by itself.

Then I'm spotting ivo://xcatdb/3xmmdr7/tap, which is produced by you
and should be easily fixed (use the opportunity to fix the
broken xsi:schemaLocation on this one), and likewise
ivo://ia2.inaf.it/tap/projects (though the schemaLocation is fine in
this case).  It might be interesting to understand where the bad
namespace URIs came from.

Finally, there's ivo://mast.stsci/ssap/befs served by STScI.  I'm
sure Theresa can quickly fix this one.

So... phewy... it's essentially three records plus something that's
already fixed with the rollout of the fix pending.

Thanks for bringing this up,

         Markus
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.ivoa.net/pipermail/registry/attachments/20210203/a25b2b16/attachment.html>