SimpleDALRegExt update

[Markus Demleitner]

Dear Registry folks,

In the context of getting the note on discovering data collections
endorsed, I promised to add the S*AP-related capability identifiers
mentioned there into SimpleDALRegExt.  After a bit of
procrastination, I've done that now, which get us on the way to
SimpleDALRegExt 1.3.

While eyeballing the rest of the standard, I thought this little
overhaul might be a good opportunity to introduce a few further minor
changes:

(1) Drop the SSAP SpaceFrame type, which contained lots of STC-1 terms we
    scuppered for now, and use the new http://www.ivoa.net/rdf/refframe
    vocabulary that STC2 will (hopefully) introduce.

(2) Admonish people to compare standardIds case-insensitively.

Point (1) might in principle invalidate existing service records,
because our new list is a good deal shorter than the old one.  In
reality -- run

select * from rr.res_detail 
where detail_xpath='/capability/supportedFrame'

on the RegTAP service of your choice -- that only affects a single
service, ivo://au.csiro/casda/ssa, and that could be easily fixed by
replacing GALACTIC_II with GALACTIC in the resource record.  The
alternative -- keeping a list in conflict with STC2 (whatever that
will eventually look like) around -- appears a lot less desirable.

That's the status I've put to
http://docs.g-vo.org/SimpleDalRegExt.pdf now, and you can see it (and
the history) on 

https://volute.g-vo.org/svn/trunk/projects/registry/SimpleDALRegExt

(up to rev. 5649).  I'd really be grateful if people interested could
have a brief look at things and see if perhaps they'd like to change
something else yet.

Me, I'd like to do another change, and that's probably a bit more
contentious: I'd like to get rid of ProtoSpectralAccess.  That's a
type like SimpleSpectralAccess but a bit different, and I feel it's a
a minor disgrace to have that backwards compatibility shim still in
place after, what, something like a decade.

There are still four services around that use it -- try

select * from rr.capability where cap_type='ssap:protospectralaccess'

if you don't take my word for it.  I've contacted the authors of the
corresponding resource records and asked them if they couldn't
migrate.  Assuming they do that: Would anyone object to dropping the
type?  Yes, in a sense it's an incompatible change, but if there are
no active records using a type and it's obvious it should never be
used again... well, can't we bend the rules a bit?

          -- Markus