Hi All -
I sent a query to Ray for a clarification of the official Registry WG position on this, plus invited comments from NVO. Some responses have been received, but I will wait a while longer and then forward all such comments received.
Another use-case to think about in the meanwhile, is a tabular service which returns virtual data. In the case of a service which returns virtual data, the table is constructed on the fly in response to the client request. This has proven to be a quite useful feature with other forms of astronomical data within DAL. In the case of dynamic generation of a virtual table, the table fields generated may well depend upon the actual query received.
We can think up any number of examples of this, but one which came up recently in another project I am working on, is a catalog service which computes thousands of image cutouts from survey data, then computes some morphological quantities via image analysis of each cutout, returning a table containing the results. This "dynamic table" could then be combined with data from conventional source catalogs to provide a powerful, user extensible object detection technique.
A simpler example might be a service which can return data from multiple catalogs, e.g., by specifying the collection name as a query parameter. For example, if a survey data collection includes several catalog data products, it might be reasonable to serve these up with the same service. This leads to the concept of a "table set", which the ability to query the metadata of each such table.
Service metadata, and getCapabilities/VOResource would seem to be intended to describe the more static capabilities of a service. In the case of virtual data however, or table sets, metadata describing the dataset to be accessed can be more dynamic. Even in the case of static tables, metadata such as a list of table fields can be very large; some of these tables can have hundreds of fields. This suggests that table metadata is more closely tied to the data than to the service, and perhaps should be handled with a more data-oriented mechanism.