Doug
You are right in principle in all that you say.
> It has always been this way (except for cone search, which is the
> trivial exception). SIA V1 has FORMAT=metadata, which returns service
> metadata; this is the previous incarnation of getCapabilities.
And that is why the SIA services that I have built are not listed in the
VO registry -- because they are not complete, which is because I never
got around to the FORMAT=metadata section. But I use them and find them
useful all the same. If the specification did not have so many MANDATORY
pieces, there would be a lot more astronomical data available, although
the services would be less uniform.
> getCapabilities tries to be more compatible
> with an actual VOResource record.
This is of course a nice model -- the service acting as its own "micro-registry". But the problem is that services are now much more difficult to implement: all the UCDs and utypes for the output table, the heartbeat services and logging with the RunID, and now the requirement to create a giant complicated XML document.
Where is the software support for all this *mandatory* functionality? The actual astronomy logic is a tiny part now of all the IVOA complexity that surrounds it. This would be perfectly OK if there were software and documentation and tutorials about how to make a VO service. Who is making the "service provider package" so that data providers can just install and tweak, and moreover do it with their favorite language? Another question: is there a SINGLE service out there that does ALL the tricks (heartbeat, capabilities, logging, WSDL, STC coverage, etc)?
> if anything changes the service implementation
> can update (or even autogenerate) its own service metadata,
I do not agree, and here is my scenario. What the original implementor did was to copy a record from the registry and edit it with Notepad, without really knowing much about XML or VOResource. When the result is not valid XML, there will be a delay of 3 months before trying again. When there are changes to the service, the implementor will probably do nothing, not wanting to dive into the horrible XML again. When the Registry curators come calling saying your VOResource is broken, the implementor may go back to the registry and attempt to use the publish/update forms to make the changes, but then harvesting happens and the edited version is replaced by the old one from the service itself.
It seems we are just dumping more and more work on the service implementor, but without making the bulletproof infrastructure that they need to do the job effectively.
Roy Received on 2007-04-25Z23:01:39