DataLink inputParam PARAM/@value

[Mark Taylor]

On Mon, 20 Nov 2017, Markus Demleitner wrote:

> Hi Carlos, Hi DAL,
> 
> On Fri, Nov 17, 2017 at 11:06:41AM +0100, Carlos Rodrigo wrote:
> > In practice, trying to define how to build a meaningful interface
> > (let's say, a form) just using a "metadata" response has several
> > subleties when we really think of real cases.
> 
> True.
...
> For instance, in SODA, there's both CIRCLE and POLYGON, and I'd like
> to read the standard as "Clients must not pass in both CIRCLE and
> POLYGON at the same time."  There are many other cases in which
> relations *between* parameters need to be declared (even if you
> thought SODA should just take the union of different inputs); I think
> at least "if you give this param, you also have to give that" would
> be desirable in addition to mutual exclusion.
> 
> Sure, you could write INPUT:CIRCLE:conflicts=POLYGON -- but then
> at least for debugging it becomes quite a chore figuring out the
> complete dependency or avoidance graph; writing down explicitly, in
> some syntax:
> 
> conflicts(CIRCLE,POLYGON)
> 
> seems preferable at least if it's not terribly much more work for
> spec, service, and client authors.

My general feeling on this sort of thing is that it's hard to come
up with external descriptions that do a good job
of encoding constraints on linked sets of parameters.
MIN, MAX and OPTIONS are probably reasonable, though even with those 
there's scope for abuse and confusion; e.g.

   % curl -s 'http://dc.zah.uni-heidelberg.de/boydende/q/dl/dlmeta?ID=ivo%3A//org.gavo.dc/%7E%3Fboydende/data/fits/HAR081_004308.fits' | xmllint -format - | grep -A5 POLYGON
      <PARAM arraysize="*" datatype="double" name="POLYGON" ucd="phys.argArea;obs" unit="deg" value="">
        <DESCRIPTION>A polygon (as a flattened array of ra, dec pairs) that should be covered by the cutout.</DESCRIPTION>
        <VALUES>
          <MAX value="13.5628982448 -74.8092154585 11.8908923667 -72.0023786878 2.6858408712 -72.2229858075 2.6979056912 -75.0567925826"/>
        </VALUES>
      </PARAM>

- as a human I can probably guess what that means, but I'd never
have thought to write code that could understand it if I hadn't 
seen this kind of example.
Moreover, the MIN, MAX and OPTIONS for one parameter are often 
a function of the values for other parameters.

As a builder and to some extent user of UIs, I'm generally more 
in favour of good human-readable documentation provided by the service
(per-parameter descriptions of value constraints, comprehensible
error messages for bad inputs).  Trying to specify (not to mention
to use on server and client side), a machine-readable language for 
describing constraints is in my view likely to lead to syntax
which is pretty complicated but still unable to capture all the 
things you need to say.  I'm afraid my recollection of the details
of PDL does not dissuade me from that opinion.

Mark

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