Aperture in ssap

[Markus Demleitner]

Hi Carlos,

On Tue, Jul 18, 2017 at 08:14:39PM +0200, Carlos Rodrigo wrote:
> I don't intend to discuss now why this is mandatory. Just how I can
> implement a SSA service including a mandatory field which value I
> cannot fill.
> 
> I wonder which of this would be better:
> 
> <PARAM name="aperture"
> utype="Char.SpatialAxis.Coverage.Bounds.Extent" datatype="char"
> arraysize="*" value="">
> 
> <PARAM name="aperture"
> utype="Char.SpatialAxis.Coverage.Bounds.Extent" datatype="double"
> value="0">
> 
> <PARAM name="aperture"
> utype="Char.SpatialAxis.Coverage.Bounds.Extent" datatype="double"
> value="null">
> 
> any other idea?

My vote definitely is for value="" -- while I don't think current
VOTable explicitly says that PARAM/@value must be parsed using what's
used for TABLEDATA/TR/TD, I'd say that's definitely the intention,
and then the empty string is the right way to give a NULL (a
VOTable-compliant alternative would be writing NaN, but I suspect
there's more actual code out hthere hiccupping with that).

A final alternative (one that I'd liked to have seen deprecated in
VOTable 1.3, but that didn't happen) would be something like

<PARAM name="aperture"
  utype="Char.SpatialAxis.Coverage.Bounds.Extent" datatype="char"
  arraysize="*" value="-1">
  <VALUES null="-1"/>
</PARAM>

-- but I suspect even less code would cope with it, and there's many
practical issues with this sort of null value specification for
floating point values.  So, let's not go there.

0 you shouldn't give, as that could be an actual value (in this
particular case perhaps for a dark frame), and null simply is not a
legal floating point literal at all.

As to having a mandatory SSAP parameter be NULL, practice has been
cavalier from the start; most theoretical services can't give
positions, for instance, and clients have coped.  When we review SSA
(or a future 1D dataset access protocol supplanting it), we'll have
to discuss what conclusions are to be drawn from that.

          -- Markus