New version of VO Support Interfaces: v0.26

[Roy Williams]

We have come a long way from Simple Cone Search.  If a developer wants 
to expose a catalog by IVOA service, it turns out to be pretty 
complicated, with all the MUSTs and SHOULDs and REGISTRY full of 
complicated XML. The service developer has to do these:

-- UCDs for the output table,
-- Heartbeat and uptime services, next scheduled downtime
-- Recording usage in special IVOA logging format
-- Passing a RunID tag from place to place
-- Choosing a registry interface, reading the RM document, filling in 
the form
-- Implementation of getAvailability, getCapabilities, getRegistration, 
metadataLastChanged etc etc
-- STC document describing coverage of the service
-- A SOAP interface including a WSDL document
-- A REST interface that works with nice "resources" and has no nasty 
dirty "verbs"
-- Understanding complex multi-layered XML and making it all valid

....... and soon there will also be
-- Units for each column in proper format
-- Implementation of TAP protocol
-- Connection to IVOA data model and relevant utypes in the output table
-- Bulk access interfaces for inventory, bulk crossmatch, etc

Questions
(1) Can the IVOA support this level of complexity?
(2) Where is the robust software that leads the service developer 
through the maze?
(3) Can the IVOA Recommend any of the above standards in the absence of 
that implementation software?
(4) If somebody makes a service that has fabulous science data but NONE 
OF THE ABOVE, should the IVOA reject it?