Hi Pat -
My apologies for not being able to explain this more clearly (also, we are getting side-tracked from the TAP issues, but I will explain the point I was alluding to in more detail anyway).
I was making a general statement on the two approaches of 1) directly mapping a data model into XML, and 2) mapping the same information into a generic container. This point was not specific to VOResource at all, but to the general issue of a custom XML representation vs a generic container for representing data.
As a general design issue, this comes up all the time in many areas in VO. A direct serialization of a data model in XML often seems like the simplest approach, but it requires a custom schema, and therefore custom code, for every class of data (data model). The generic container approach is more complex for a single class of data, but wins overall in many real world cases, as many classes of data can be represented in the same generic container, with reuse of all the associated software, plus the mechanism has other advantages such as being inherently more extensible. Generic tools can be written to work on the generic container regardless of what data is stored therein.
This approach has been very successful within astronomy, as witness the heavy use of table data formats and associated tools. Relational database technology has been very successful for the same reason. The table mechanism in a RDBMS is also a generic container, with a great deal of useful technology which can operate upon data represented in this format.
Anyway, this is what I was getting at.
On Fri, 9 Mar 2007, Patrick Dowler wrote:
> Now I am confused. Are you saying that using XML to describe table metadata
> will require a new custom schema or not? Considering that VOResource is an
> existing XML schema with (some) ability to describe tables... or are you
> just saying we will have to use a custom schema?
If we decide to support a native XML format for table metadata, so far as I know (not having looked at VOResource that carefully) I see no reason this could not build upon the work done on tabular data in VOResource. Even if we return table metadata in another format such as VOTable, we should probably still look carefully at VOResource as the information content (data model) will still be relevant. We should look at other things as well such as SQL information schema and presumably the work already done on the Catalog data model.