> But if the metadata for a table is available in some standard way (eg
> in the registry)...
Thats fine, but what if the meta-data isn't in the registry, or what if you're using the VOTable (or whatever XML document we're talking about now!?) to do service to service communication. What if both these services are fairly low level? Are we going to make (demand) every service is registry aware? Surely that's going to be a massive overhead we want to avoid?
> ...then is it not possible for the results of a query to simply
> _reference_ the original table's metadata (via namespacing perhaps)?
> A join could reference the metadata from all the tables involved with
> equivalent namespaces.
Yes, but! What happens to simple at this point? While its an elegant enough idea if we start to get too complicated the astronomer on the street is going to just not use our stuff.
The real problem VOTable solved (for me) was having the meta-data just there, with the data (or at least with a URI pointing to the raw data).
Putting the meta-data somewhere else seems to totally defeat the purpose, at least from my point of view....!?
> Biggest drawback is having the metadata to hand but ubiquitous
> registries should take care of that.
Yes, but! Ubiquitous registries is all very well, but we need "simple services for simple tasks", we should be doing things as simple as possible.
Demanding every service has to be able to talk to the registry to pull back meta data for catalogue queries would not be good. It would also double the number of network calls (every service you passed this document to might have to talk to the registry! ick!).
> How does that sound?
Err, I'm not convinced!
Al.
-- Dr. A. Allan, School of Physics, University of ExeterReceived on 2004-01-19Z22:11:26