Doug, Pedro, et al.,
Sorry I've fallen behind on this discussion. You guys have respectfully tried to bring me in, but it seemed so daunting ;-)
I do want to catch you up on how I have been involved "behind the scenes" and make some observations along the way. Doug and I have discussed getCapabilities() in the context of SSA. The early dicussion centered on the question, does the metadata Doug wants to be returned by getCapabilities() covered by what we do in VOResource. My conclusion was not only was it covered, but it also it wasn't "over-covered"; that is, the desired capability description is essentally the information put in the registry.
The two attached files illustrate this. One shows a mapping of the capabilities metadata from the SSA document. The other is a sample VOResource document that captures this information. It assumes that VOResource has been extended in the standard way to capture the SSA-specific information.
Now, I claim that it is the responsibility of the developers of an IVOA standard protocal (like SSA & TAP) to define the protocol-specific metadata that is to appear in the registry. In particular, they need to define the specific VOResource extension schema in the standard way. To help with this, I will be giving a short tutorial on how to do this extension at DAL1 and REG2 in Beijing.
OBSERVATION #1: Whether or not we have a getCapabilities() method, the
SSA and TAP authors have to define their capability metadata.
We know it is not trivial for an end publisher to create VOResource records: a tool is needed to create them, and a tool is needed to check them (and a person is needed to make sure they make sense!). These tools are not cheap to create; nevertheless we have built them: the first one is the resource registration page that is part of each public registry, and the second one is a validater that I have just deployed.
OBS #2: If we make service providers serve their own VOResource
record, the easiest way to provide them with the authoring and checking tools is to provide a "download" VOResource button on our registration pages.
OBS #3: If someone provides other tools that provide these functions,
that is no problem for registries.
Many people for a long time have argued that services should be self-describing, the two main reasons being:
OBS #4: If services are self-describing, the process of registration
becomes simpler, only because the publisher has already paid the price
of describing the capabilities.
As long as updating capabilities is a matter of the developer/publisher updating a static file, then I'm dubious as whether it will be kept more up to date if the file lives with the service or with the registry. Only when this information (or at least the bits most likely to change) gets generated automatically by the server software (because it can detect its own capabilities) does argument a. make sense to me. There's an advantage, though, if it resides at the registry: the registry can check the validity of the description while it has the publisher on the hook. If it is at the service, it's a bit more complicated contacting the publisher when the description goes bad. Nevertheless, I like to be open to innovation, and we can probably deal with this one.
OBS #8: Client capability negotiation is a new thing in the VO; we
currently have have no (little?) software/experience making use of it.
OBS #7: if getCapabilities() is essentially about returning a VOResource
document, then it is essentially identical to the getMetadata() that was proposed by GWS as part of the support services standard.
One way we discussed deploying the support services standard was as a set of optional functionality added to a service. We would encourage support for the standard as a way of reaching a "gold" status.
My own recommendation regarding getCapabilities() would be to spin it off as an optional bit (a la the support services standard) that can be easily made part of any DAL service. This would allow us to go ahead and deploy it with new services and get more experience using it. We need time to develop support for it in the registry as well as in other client software. In the future, new DAL specs could say "you MUST support the support services spec vX.X".
hope this helps,
Ray