Error column in VOResource

[Tony Linde]

> (2) VOTable is perfectly good XML. 

Only in the sense that it has lots of angle brackets: xml it is, *good* xml
it certainly is not. Looking at <td>7.3</td> is not, to my mind, very
meaningful. In order to understand what it is 7.3 of, you have to interpret
some arcane TABLE/FIELD structure, count along the right number of FIELD
elements and, voila, you still don't know what you've got. Whoever
constructed the VOTable could call that field whatever they want and then
call it something else in the next VOTable they send you. You cannot do
anything but display the data with the name as a column heading; it is
semantically useless. Adding a UCD to the field helps but you'd better hope
that there's only one such UCD in the dataset.

Tony.

> -----Original Message-----
> From: Roy Williams [mailto:roy at caltech.edu] 
> Sent: 18 May 2004 16:33
> To: Tony Linde; registry at ivoa.net
> Subject: Re: Error column in VOResource
> 
> 
> > I wasn't saying that Martin's was any better but that we 
> should wait 
> > for
> DM
> > to complete so we have a base metadata schema to work from. And that
> schema
> > should be based on XMLSchema not something like the VOTable 
> > TABLE/FIELD construct for which we have to write all new 
> interpreters 
> > instead of starting from standard tools.
> 
> (1) DM is not working on any more data-structure modelling, 
> they are working only on semantic modelling (see architecture 
> document section 4). I do not see any progress on the former, 
> so we are on our own.
> http://www.ivoa.net/internal/IVOA/IvoaArchitecture/IVOarch4.htm
> 
> (2) VOTable is perfectly good XML. The problems with the XML 
> tools arise with their restriction to static typing that is 
> compiled in. However VOTable has dynamic typing -- you don't 
> know until runtime what datatypes are in the table.
> 
> However I will point out that if we use VOTable for the 
> header only, then the standard tools work well. This was 
> always the intention: that the header can be used 
> independently to describe table metadata, and the data can be 
> in some other format.
>