On Fri, 9 Mar 2007, Patrick Dowler wrote:
> 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).
The tabular part of VOResource *is* a custom schema for representing a table. I wasn't suggesting inventing a new one, just pointing out that using native XML requires a custom schema for each class of data, and therefore custom software, as opposed to the generic container approach.
> 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
The key point is that table/column metadata is inherently tabular in nature, hence a uniform approach can be used for both table metadata and data. I think this is a fairly compelling thing to exploit as it is not a trivial thing to parse a table, load it into memory, provide an API to walk through the table, get attributes from each row, possibly hash the values to provide an object API, etc.
The classical use of VOResource for service capabilities is another matter. A client application will probably only make light use of this data; it may possibly not use it at all, if it requires only the "must provide" capabilities of a TAP service. If a client does use the capabilities metadata in many cases it will be a matter of a few GET calls to query individual capabilities.
> 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.
Since TAP will stand on its own as a service independent of the registry, clearly TAP has to specify the table metadata in any case. We may wish to base the data model (I assume this is what you mean by semantics) on what has been done for VOResource, but this is a separate problem from specifying what is used for the metadata access interface, and has to be addressed with either approach.
> 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.
I don't know, but I suspect that VOResource cannot currently handle the multiple table situation at all. Has anyone looked at it carefully enough to determine this?