On Friday 09 March 2007 06:54, Doug Tody wrote:
> If native XML is used to convey table data, we have to invent a new,
> custom schema just for this class of tabular data. Applications may
> have to use different software to access table metadata and table data,
> even though both are tables.
This I have to take exception with: no one is talking about inventing a custom schema and that is in fact the whole point: VOResource already exists, is way ahead of TAP in the standardization process, and describes this stuff (more or less - if less then RFE).
Applications that use TAP will have to know about VOresource for service metadata and they will have to know about whatever tabular model (VOtable, whatever) for the data itself. The table/column metadata is in between and I don't see using either of these approaches as requiring more parsing software. But, as has been mentioned, VOResource does specify semantics and VOtable does not, so VOtable requires a secondary effort to specify the semantics. Now, that could well be INFORMATION_SCHEMA, which is just requiring the TAP service to have some metadata tables.
What I don't know about INFORMATION_SCHEMA is how well it tells the user how to make joins and what the cardinality of such join relations will be. People who actually write SQL queries have to know that kind of stuff once they get past single-table queries or else they will not be able to formulate the query and understand the result. I also do not know if (or expect that) VOResource can currently express this sort of information succinctly either.
-- Patrick Dowler Tel/Tél: (250) 363-6914 | fax/télécopieur: (250) 363-0045 Canadian Astronomy Data Centre | Centre canadien de donnees astronomiques National Research Council Canada | Conseil national de recherches Canada Government of Canada | Gouvernement du Canada 5071 West Saanich Road | 5071, chemin West Saanich Victoria, BC | Victoria (C.-B.)Received on 2007-03-09Z19:36:12