New version of VO Support Interfaces: v0.26
roy at cacr.caltech.edu
Mon May 7 15:31:30 PDT 2007
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
-- 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
-- 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
(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?
More information about the grid