empty param values in votable

Dubois-Felsmann, Gregory P. gpdf at ipac.caltech.edu
Mon Jul 20 18:09:08 CEST 2020


+1 for not hacking this with a change to PARAM.

I'm all in favor of doing this more systematically.

Gregory

________________________________________
From: apps-bounces at ivoa.net <apps-bounces at ivoa.net> on behalf of Markus Demleitner <msdemlei at ari.uni-heidelberg.de>
Sent: Monday, July 20, 2020 6:47 AM
To: apps at ivoa.net
Subject: Re: empty param values in votable

Hi,

On Fri, Jul 17, 2020 at 06:17:59PM +0000, Dubois-Felsmann, Gregory P. wrote:
> This could be relevant to an SIAv2-like DALI API where a query
> parameter, if present, specifies a restriction (e.g.,
> "DPTYPE=image"), and the service author would like to make it
> possible to select records where the corresponding parameter is
> NULL or empty.  That is, what if we want specifying "XYZ=" (with an
> empty value) to mean something different from not including the XYZ
> parameter at all?

Currently, you cannot.  We might be tempted to hack something by
releasing the requirement for @value on PARAM, but to me this is a
special case for the more general problem of talking about service
interfaces' parameter requirements; another rather common case takes
the form of "If you pass parameter X, you must [not] pass parameter
B".

A motivating example for that: DaCHS cube cutout services let you
specify your constraints with COORD_n (in pixels) or using WCS (in
physical units).  Because it's hard to define what to do and because
we'd likely be camouflaging user errors otherwise, DaCHS refuses to
do anything when an axis is constrained by both COORD_n and a
corresponding physical constraint.  Since DaCHS knows when to say no
up front, it could declare that in its Datalink service block, and
advanced Datalink UIs might make good use of that (e.g., disabling a
field when a conflicting field has been filled).

We even have a standard that would let us do that: PDL.  There are
two reasons why that doesn't immediately help us: PDL isn't yet
translated to VO-DML (that's easy to fix), and we still don't know
how to put all this into VOTables (that's hard to fix, because that's
the "DM annotation" thing that's been contentious at least since the
Madrid interop).

         -- Markus


More information about the apps mailing list