Re: New version of VO Support Interfaces: v0.26

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? Received on 2007-05-08Z00:31:57