TAP questions
Mark Taylor
m.b.taylor at bristol.ac.uk
Fri Mar 9 10:39:15 CET 2018
On Fri, 9 Mar 2018, Markus Demleitner wrote:
> On Fri, Mar 09, 2018 at 12:45:31AM +0000, Dave Morris wrote:
> >
> > On 2018-03-07 08:52, Markus Demleitner wrote:
> > > Well, so far in the VO we do not really distinguish between the
> > > various VOTable serialisations, except perhaps that external FITS
> > > entities may confuse many libraries. So, if you're ordering VOTable,
> > > there's no guarantees whether you'll get back BINARY or TABLEDATA.
> > >
> >
> > There are cases where users will want to process the results as XML,
> > possibly using something like an XSLT parser, in which case they will want
> > some way to be able to specify the XML form.
>
> Hm. This is what VOTable 1.3 says:
>
> This type may be accompanied by an optional parameter "serialization"
> with a value specifying the serialization type used for table data
> within the document, one of TABLEDATA, FITS, BINARY or BINARY2,
> interpreted case-insensitively. In the absence of this parameter, any
> of the serializations may be encountered. If multiple different
> serializations are used in the same document, this parameter must not
> be used.
>
> It's pretty clear to me from this language that a client can have no
> expectations in general that a given service must be able to produce
> serialization=TABLEDATA just because it's producing VOTable. And I
> think there's no way VOTable could change this with reasonable
> specification effort.
Just to muddly the waters further, I know at least one place where
TABLEDATA is mandated; DataLink 1.0 sec 2.1.2 says:
"The only output format required by this specification is VOTable
with TABLEDATA serialization [5]; services must support this format."
--
Mark Taylor Astronomical Programmer Physics, Bristol University, UK
m.b.taylor at bris.ac.uk +44-117-9288776 http://www.star.bris.ac.uk/~mbt/
More information about the dal
mailing list