TAP questions

[Markus Demleitner]

Hi DAL,

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.

I could, however, see a change to DALI that would say something like
"Every DALI-compliant service that produces VOTables must respond to
a request with RESPONSEFORMAT for a VOTable media type with
serialization=TABLEDATA with a TABLEDATA-encoded VOTable."

I have to say I'm not sure I'd be a big fan of such a regulation --
while I believe for the major frameworks this is no big deal (and
many probably already work that way), it certainly raises the bar for
compliance by yet another notch.  We should at least understand well
why clients might really want that, in particular now that full
VOTable implementations exist even in javascript, so the in-browser
processing that was a common use case for this kind of thing can deal
with full VOTable.

So, from me a decisive +/-0.

       -- Markus