Hi all,
This issue obviously affects many WGs and it is a good thing to discuss it openly in the different lists. I will present ESAVO point of view, which we already detailed a few times, more recently on the VOQL-TEG list regarding TAP, but I'll try to summarize it here as clearly as I can.
We consider 3 different types of Metadata :
The Registry is not just a cache for any of this information. It was not
designed with the idea of just being a cache and changing the ideology
now that the design is done might not be a good idea. The Registry
should be the source for the Resource and Service Metadata, and it
should be inserted directly there.
The Table / IO Metadata must obviously be accessible from the Service
itself, and some Registries do not want to handle this information as
the coarse/fine-grained debate showed. Hence, this metadata should
originate from the Service. Fine-grained Registries can then harvest
this information if desired. This is where those Registries work would
be much simpler if all the Services would provide this information in a
standard fashion (same access point method or Ray's pointed URLs idea,
same output format - specific VOResource elements).
If people feel that it might be useful to access the Resource and
Service Metadata from the Service itself, an optional standard method
call could easily "proxy" this from the Registry. Meaning that the call
would only redirect to the Registry entry without the client being any
the wiser about any Registry system.
In the end that makes one method on the Registry to get the VOResource record, one on the Service to get the Table / IO Metadata and eventually one on the Service to get the VOResource record. All coarse, fine-grained, service or registry source-for-the-metadata people should be happy and be able to do the calls the way the want to. Those that want to handle the full VOResource record at the Service should even be able to do so, having an agreement with a particular Registry that it will harvest them every x days to update itself. This mechanism shouldn't be considered standard though and be handled outside the VO.
Comments are welcome, but I guess discussions will be much easier next week in Beijing.
Cheers,
Aurelien