VOTable 1.1 - XPath to data in header

[Guy Rixon]

On Wed, 9 Jun 2004, Martin Hill wrote:

> Guy Rixon wrote:
>
> > Martin,
> >
> > sounds good.
> >
> > Can you clarify whether the paths are absolute
> > (//VOTABLE/RESOURCE(1)/TABLE(42)/DATA/TABLEDATA/TR(666)/TD(14)) or
> > relative (../DATA/TABLEDATA/TR(666)/TD(14))?  Or is this a choice of the
> > writing software?
>
> Interesting question.  I would have thought it wouldn't matter to any
> processing software, and relative would mean VOTables could be included
> in other documents and the path still work.  Is there a call for that?

Yes, good point.  We at least want to include VOTable in SOAP.

> >
> > What happens if there is no DATA, or if there is DATA but no TABLEDATA? (Plug:
> > DFDL will eventually allow an XPath into an included binary or FITS file.)
> > Can we write nil="true" in these cases?
>
> Hmmm in the case of any attached/referenced XPathable data the XPath
> would refer to the right elements within that data.  If there is
> attached data but it's not XPathable I would have thought there should
> be some indication of this... If there is no attached data (although I
> thought we were using VOResource to describe metadata?) then it would
> make sense that the element was missing altogether to show this...

OK, but the W3C XML schema language can't enforce the presence of the XPath
attribute conditional on the presence of TABLEDATA. Mind you, it can't enforce
that the right path to the TABLEDATA is given either.

>
> > On Wed, 9 Jun 2004, martin hill wrote:
> >
> >
> >>Hi all
> >>
> >>(A suggested addition to make VOTable more 'proper XML')
> >>
> >>I appreciate I didn't get a chance to present this formally to the VOTable
> >>group at Boston (much to your collective reliefs I was attending other
> >>meetings!).  However I have spoken to several people about it who have
> >>appeared agreeable, and it would solve a major 'proper XML' problem associated
> >>with VOTable.
> >>
> >>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.
> >>
> >>This means (I believe) that using standard tools we can extract *columns*
> >>based on UCDs, etc and transform (eg using XSLT) into anything else, using
> >>this element. Basically any tools examining the header will have direct access
> >>to the correct column elements, without having to write special code to work
> >>out position information.
> >>
> >>It has to be mandatory otherwise we cannot be sure of transforming documents
> >>and so will have to write special position-based code anyway.  However it only
> >>requires changes to the VOTable-serialisers, not to any other software, as the
> >>XPath is fixed for each FIELD 'position'.
> >>
> >>I can do an example if people require (I'm typing this between lessons on a
> >>course just now though) but I think the concept is simple, requires very
> >>little work, and should give us a great bonus in making VOTable usable by
> >>standard XML tools.  Just think how much quieter this email forum will be
> >>without Tony & I complaining all the time :-)
> >>
> >>Cheers,
> >>
> >>Martin
>
> --
> Martin Hill
> www.mchill.net
> (07901 55 24 66) - from 17th June
> 0131 659 6426 (home)
> 0131 668 8100 (ROE)
>

Guy Rixon 				        gtr at ast.cam.ac.uk
Institute of Astronomy   	                Tel: +44-1223-337542
Madingley Road, Cambridge, UK, CB3 0HA		Fax: +44-1223-337523