DataLink inputParam PARAM/@value

[Markus Demleitner]

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.

> But you can think of some others. For instance, does the service
> allow for a range or a list of values for a given parameter? or
> even, for a text field, can I use wildcards for that field?

Well... "deep" syntax like wildcards, I think, is yet another level
beyond types and such, while intervals can indeed already be declared
in current datalink/DALI with xtype="interval".  But you're right,
declaring parameter metadata is highly non-trivial, as is also
evidenced by the existing IVOA standard for that, PDL.

> You can think of simpler alternatives for all that. But, when we
> defined S3 (that tried to deal with these problems) we thought of a
> way to specify these options (you can take a look to a summary at
> http://svo2.cab.inta-csic.es/theory/docs2/index.php?pname=S3/Interface
> just for some ideas)
> 
> for instance,
> 
> <param name="INPUT:COLLECTION:fixed" value="ALL"> would work as
> "the value for "COLLECTION is "ALL", and you must pass it like that
> to the service, not ask the user for a value.

I'm not *terribly* hung up on the syntax for the additional metadata,
though certainly if we have VO-DML, it would be a shame not to use it
for something like that.

But "tags" on individual PARAMs don't seem to be ideal for this since
one of the most common use cases is IMHO very clumsy in such a
formalism: Declaring mutual exclusion.

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.

> if a non empty VALUE is provided: - if there is a VALUES child
> element, this field should be filled in a form.  - if there is not
> a VALUES child element, this param is fixed and it must be passed
> by the form with that value fixed (let's say, as a hidden field)

Yes, that was what last week's proposal was intended to convey.

> what's more, if VALUES provide real information: 
>
> - if VALUES->MIN/MAX you just, for instance, include some text
> giving information of the MIN/MAX values allowed.  

> - if VALUES type="actual" and there are non-empty OPTIONs as
> childs, you make some select field with all the possible options 

Yes on both.

> - if VALUES type="actual" and there are NOT non-empty OPTIONs as
> childs, it must be understood that the param should be filled
> (because there is a VALUES child element) but its content is free
> (because you don't have options to show)

I'm not so sure about this.  It's certainly tempting to abuse
VALUES/@type to indicate whether or not a service parameter needs to
be filled, but frankly the reek of a bad hack is fairly dense in the
closer vicinity of that idea.

I'd say: let's try and get a VO-DML version of PDL out as fast as
possible, and let's get the VO-DML mapping spec cleaned up and
passed, and we'll have a way to declare all the various subtleties of
service interfaces within VOTables that's fitting in seamlessly with
the rest of the VO.

     -- Markus