a recipe for crumpets

[Ed Shaya]

Martin Hill wrote:

>
> > Perhaps you want to drop the table view entirely?
>
> I don't want to lose the ability to pass generic tables of data about, 
> or lose the current toolsets that work with VOTable - which is why I'm 
> happy to see VOTable stay as it is - but I do want to drop it 
> (entirely) for the *default* service data exchange format.
>
  Well, it is not surprising that there were not many takers for this 
idea at the VOTable discussion group.  You may find more sympathizers 
here at DM though.  Personally, I have always advocated passing a hybrid 
that consists of an XML description of a table plus a file of either 
fixed width ASCII or binary, perhaps packaged in SOAP or as an SMTP 
message+attachment.  This is not totally at odds with VOTable schema, 
although thus far application writers have been pushing the <TD> 
option.  Now, as we have been discussing, one can incorporate much 
better semantics and validation if there is a properly modeled view, or 
layer, of the hybrid container.
    Perhaps when the exchange is about a few objets then one can use the 
model view directly,  But, I think it is a given that when the number of 
objects being discussed reaches into the many 1000s, as is typical in 
astronomy, then we simply must switch over to the hybrid tabular 
representation.
  As for the model view, the basic concept of XML is to have information 
bracketed by start and stop tags that are descriptive of the info. And 
to allow subsections of this info to be tagged in a nested matter.  When 
done properly a single XPath request finds the desired object and 
retrieves the whole twig of nested relevant information.  Tables are 
missing this property.  We absolutely need this capability to ensure 
background information (aka. metadata)  is discoverable and indepth.
  Plain tables have served the human eye well for thousands of years 
because it has always been supplemented with human readable text.  You 
understand a table in a scientific article because you have read the 
article.  If you have not read the article, you most likely do not 
really understand the table.  Although we have no real substitute for 
reading the literature, much analysis can be automated provided certain 
key information is entered along with the tabulated numbers, but this 
information does not neatly fit into canonical tables.  Hence the 
tabular format must adapt to hold extra metadata about any cell.  It 
would be very useful if we have a means of making round trip from model 
view to tabular view and back to tabular view with  no loss of information.
  If we can do that, then it does not really matter whether the 
application writers use one or the other representation for I/O.  You 
might feel that it is more straightforward for them to start using the 
model view.  And I agree with you that they would lose no capabilities 
if they did.  But purely on practical grounds of speed and memory usage, 
they will probably always prefer the tabular way.

Cheers,
Ed