New version of VO Support Interfaces: v0.26

[Doug Tody]

Hi Roy -

My view is that we have to be careful to keep the system modular,
and avoid unnecessary interdependencies which make it difficult
to do anything without exposure to multiple parts of the system.
To publish data, it should be possible for a user to be able to
implement and test a data service stand-alone, ideally by reading
only one document, the service specification (no STC, no Registry
internals or schemas, possibly not even a VOTable spec if a library
is used).  The "minimally compliant" version of the service needs to
be kept simple enough to make it a reasonable job to implement with
this approach, much as SIA is now.  Completeness and robustness will
probably always be a problem with this approach however.

To go to the next level we will need interoperable service frameworks
that provide all the "recommended" and advanced capabilities in
a rigorous and robust fashion, largely transparent to the service
implementor.  The user would pick one of the user-oriented frameworks
as the basis for their service, and would only need to add the
"business logic" required to interface to their data.  This should
still be about as easy overall, as the minimal case described above.
Once we get to this level, all the advanced capabilities such as
ADQL, asynchronous operations, complex regions, VOSpace, etc.,
become mainly an issue internal to the IVOA (a nontrivial issue in
itself as things become more complex), and are largely transparent
to the user-developer.

I think ultimately we have to go this route to have a useful system.

 	- Doug



On Mon, 7 May 2007, Roy Williams wrote:

> 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?
>