res_detail key listings

[Markus Demleitner]

Dear Registry community,

You have seen that VOResource 1.2 is now in RFC
<https://wiki.ivoa.net/twiki/bin/view/IVOA/VOResource12RFC>, and the
reference implementation for the altIdentifiers has made me aware of
a nagging little problem.

Background: RegTAP has a very simple extension mechanism where, when
you have simple 1:1 or 1:n relationships to either resources or
capabilities, you define a key (in practice, the xpath of the element
or attribute) and tell RegTAP implementors to put this key together
with the value into rr.res_detail.  This is nice because not every
extension then needs a new RegTAP release (at the expense of
relatively ugly queries).

The question is: Who defines these keys and in particular which keys
must be reflected in compliant RegTAP services?

The theory has been that the extensions to that themselves.
SimpleDALRegExt
<https://ivoa.net/documents/SimpleDALRegExt/20220222/REC-SimpleDALRegExt-1.2.html>,
for instance, does this, already.  VODataService 1.2 has failed to do
that, I am ashamed to admit.

Because, you see, as a transitionary measure until the extensions
were updated, RegTAP has defined the keys for the extensions that
were there at when it was written, together with statements on
whether or not they are required:
<https://ivoa.net/documents/RegTAP/20241002/REC-RegTAP-1.2.html#tth_sEcA>.
It still does this, and I strongly suspect this is what everyone
implemented against.

But with VOResource 1.2, we should, by RegTAP rules, now list the
res_details keys coming from VOResource (grep for "(vr)" to see which
they are in RegTAP Appendix A; add to these the new altIdentifier
ones) *in the document*.  I forgot about that for the current PR.

But should I put it in?  I realised that for RegTAP implementors, and
more importantly its users, having the nice list in appendix A is
really handy.  Having to collect that list from a handful (or
perspectively a dozen) different standards is...  not terribly
friendly.

On the other hand, we really don't want to push out a new version of
RegTAP every time an Extension introduces a new key, so I don't think
we should keep having this list as the ground truth.

So... perhaps we should pull out appendix A from RegTAP and have a
wiki page with links to the relevant standards?  But then will that
wiki page be maintained each time something introduces new keys?

Well: Any thoughts on this are welcome.

Thanks,

           Markus