Elements to add to TabularSkyService

[Roy Williams]

> Sort of but not really; there are some shared attributes because the
VOTable
> header is doing a similar thing: describing the characteristics of a
column of
> data.
>
> However the VOTable header element has some rather peculiar aspects (see I
*can*
> be nice about it :-) to do with it's age (PARAM?!) and the way data is
stored in
> VOTables (array of chars?) that are not really suitable for what we want
to do
> with the metadata just now.

Words can be old and have their meaning reinterpreted. For example I
understand the word "freelance" originally meant a mercenary knight with his
own lance. Yes PARAM and FIELD are three-year-old words. I'm sure there are
more fashionable words now.

> Nor is it trivial to extract PARAM from VOTable.

Don't understand. The VOTable was made to describe table metadata. Your
VOResource extension is for describing the same thing. Remove the DATA
section and you easily turn Table into TableMetadata.

> Nor is it easy to introduce changes to the VOTable format; the concept of
> <ErrorColumn> has been turned down before,

Of course VOTable is difficult to change -- it's an international standard!
If you want ErrorColumn, then you should argue the case to the VOTbale WG
that it has greater benefit than it's cost. The answer is not to just make
up something new!

> I suspect
>  we will also need versioned UCDs for the metadata,
> so that both older and newer clients can use datacenters.

Sounds like the proper venue for this discussion is the VOTable working
group, not the registry WG.

> In fact, although I suspect VOTable advocates will recoil at the thought,
it
> will be far more useful to remove the VOTable header and replace it with a
> suitable VOResource extension (when they are ready), so that the data in
the
> table can be more fully described....

I still don't get it. Why is VOResourceTable any better than VOTable? OK,
you want to put in errors. You want tables that contain dates and enumerated
values. This is a matter for VOTable 1.2 if you care to work within the
process rather than just making a new "standard".

VOTable was designed, in part, for PRECISELY this purpose. That is why the
metadata and data can be separated so easily. The metadata then goes into
the registry.

Who is going to create VOResourceTable? If I were a developer, and I am
already delivering VOTable, I would want to simply snip off the VOTable
headers and put those in the registry. I would be rather puzzled and annoyed
to be forced to change VOTable into VOResourceTable. Who is going to parse
VOTableResource and build the search queries? What exactly do we gain by
having these two slightly different standards?