New RegTAP PR

[Markus Demleitner]

Dear Registry community,

I've just uploaded a new PR for RegTAP to the document repository.
Since we will presumably soon have a second server-side
implementation, and clients are already working with RegTAP 1.1
services, I'd say this is essentially ready for RFC[1].  I'd still be
grateful if you could have a look if you get a chance:
http://ivoa.net/documents/RegTAP/ (wait until tomorrow; or take it
from the source at 
https://volute.g-vo.org/svn/trunk/projects/registry/regtap).

There are two noteworthy changes versus the last PR:

(a) We are now requiring denormalisation of security_method_id, i.e.,
ingestors need to generate as many rows out of an interface element
as there are securityMethod children.  This is the consequence of
backing out of VOResource 1.1's restriction to one securityMethod per
interface (see also
https://wiki.ivoa.net/twiki/bin/view/IVOA/VOResource-1_1-Erratum-1).

(b) In the recommended discovery queries, we no longer constrain
intf_type='vs:ParamHTTP' to discover standard services as before.  As
discussed in RegTAP 1.0, that was essentially a workaround for
defective registry records for which the logical intf_role='std'
hadn't worked; that's no longer necessary.  Worse, abusing the
interface type for discovery leads to a lock-in to certain interface
types, which already is giving us migration headache when we want to
get rid of vs:ParamHTTP as the type of the interface in TAP 1.0
capabilities.

Comments, questions, and remarks are much appreciated.

          -- Markus

[1] Ok, the references to ADQL 2.1 and the Discovering Data
Collections EN are still missing, but that's because these documents
still are under review.