Martin Hill wrote:
> 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)....
Which means that all VOTable parsers have to understand and speak XPath?
Considering the current overheads for people writing VOTable reader/writers means that there isn't (apart from STIL) a library that implements the entire 1.0 spec, introducting something as complicated as this as a mandatory element seems uncalled for...
Al.
-- Dr. A. Allan, School of Physics, University of ExeterReceived on 2004-06-10Z10:22:47