VOTable 1.1 - XPath to data in header

[Martin Hill]

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?

> 
> 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...


> 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)