VOTable 1.1 - XPath to data in header

[Martin Hill]

Alasdair Allan wrote:
> Martin Hill wrote:
> 
>>What I would like to propose is a *mandatory* new element (<DATAPATH>?)
>>as a child of the <FIELD> element, that has as value an XPath to the
>>data elements (the column <TD> elements) that that FIELD element
>>describes.
> 
> There is no way I'd agree to this as a mandatory element. Making
> astronomers learn XPath to write a simple VOTable makes the learning curve
> too high. If it all gets too complicated, astronomers won't use VOTable
> format internally for their data and VOTable will only be used by the
> community as something they convert _out of_ rather than something that 
> contains goodness in itself (and much goodness such as UCD1+ could be lost 
> as a result). This is pretty much unacceptable...

?? Methinks you didn't read it fully...  No Astronomer would have to 
learn XPath; I'm proposing that it's created by the VOTable serialiser 
code, automatically, based on the position of the FIELD statement and 
whereever the associated data is placed (ie either inline TABLEDATA TD 
elements or XPathable attached files).  Then developers and XML-aware 
astronomers can use standard XML tools to manipulate & process VOTables 
(use case to be provided :-) rather than having to take the extra step 
of working out how to go from a VOTable header to the relevent data. 
It's intended to reduce the work of using VOTables not increase it.

(On a general point: for run-of-the-mill astronomers, VOTable - or 
indeed XML - is already an unwanted learning 'step', let alone curve. 
And we certainly don't want to encourage people to use VOTable as an 
internal form - it's an exchange format, not something suitable for 
storing (it's too big), querying (it's not indexed) or manipulating (XML 
is not suitable for dynamically changing data, such as inserting and 
removing rows, in large files).  We have to make sure that whatever we 
present to ordinary astronomers - rather than VO-keen astronomers - is 
at least readable, immediately understandable, and offers direct 
benefits over whatever they happen to be using at the time.  There are 
probably more things we should think about when it comes to 'selling' 
the VO to the astronomical community as a whole...)

> Simple interfaces for simple problems. VOTable is a perfectably workable 
> standard, lets not overload it. Keeping it as lean as possible has to be
> our top priority at this point!

Yes I agree - and at the moment we pretty much *have* to use VOTable 
tools to access data in a VOTable, which means using data in VOTable 
form is hardly lean. I would like to reduce that requirement - in fact 
I'd like to remove it but that would require some rather radical changes 
to VOTable!

Cheers,

MC

-- 
Martin Hill
www.mchill.net
(07901 55 24 66) - from 17th June
0131 659 6426 (home)
0131 668 8100 (ROE)