VOTable 1.1 - XPath to data in header
mchill at dial.pipex.com
Wed Jun 9 18:06:05 PDT 2004
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
> 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
(07901 55 24 66) - from 17th June
0131 659 6426 (home)
0131 668 8100 (ROE)
More information about the votable