additional metdata for describing columns, parameters

[Ray Plante]

DALers and VOTable-ers,

As very nicely summarized in Mark Taylor's email today 
(http://www.ivoa.net/forum/dal/0905/1236.htm), an important thread of 
discussion is how to provide additional metadata to column descriptions 
(FIELD, PARAM) that will aid applications in the handling of the data they 
contain.

I thought it might be useful to share an XML Schema technique that I have 
been experimenting with in the context of VOResource extensions (such 
as VODataService).  It's not always applicable nor always perfectly 
convenient, which I'll discuss below, but it might be useful.  Consider 
that the following could be added to the definition of the FIELD element:

       <xs:anyAttribute namespace="##other" />

What this says is that the FIELD element can contain any (globally 
defined) attribute from another schema (i.e. other than VOTable).  That 
attribute would have to be qualified with an XML prefix.

The aim of this is to allow any additional other metadata to be tacked 
on to the FIELD element as long as it has been defined by in a Schema 
document.  I think this would most useful for communicating metadata such 
as handling or transformation hints that are *specific to a particular 
application*, such as TAP.

For example, we can imagine that VOTables that go back and forth between 
a TAP service and a client would have FIELD elements with an attribute 
like 'tap:ADQLtype="TIMESTAMP"' to indicate an TAP-specific interpretation 
of the data.  Any application that understood tap:ADQLtype could treat the 
data values as timestamps; those that did not would have to treat it as 
whatever is given in the "type" attribute.

Where this solution is less appropriate is as a solution to a problem that 
spans across applications.  The problem of relating STC information would 
probably fall into this category.  There in lies a downside of the 
solution: it could lead to addressing general VOTable handling problems 
through ad-hoc solutions and thereby reduce interoperability.

Another disadvantage may be in considering the case of uploading tables to 
a TAP service and how this specialized metadata gets into the VOTable.  If 
the anyAttribute were incorporated into the VOTable standard, then 
presumably VOTable libraries could be updated to allow arbitrary metadata 
to be added to the FIELD elements.  Furthermore, TAP services would have 
to be lenient about the existance of TAP-specific metadata; otherwise, we 
would lose the ability to upload arbitrary VOTables.  But if extra 
column information is usually needed to upload a table, would it matter if 
it was encoded in a standard VOTable attribute or something customized to 
TAP?  I'm not sure.

I hope this doesn't confuse the issue.

cheers,
Ray