DataLink inputParam PARAM/@value

[Markus Demleitner]

Hi Mark,

On Wed, Nov 15, 2017 at 11:15:26PM +0000, Mark Taylor wrote:
> On Wed, 15 Nov 2017, Markus Demleitner wrote:
> > Essentially, PARAMs that can or must be filled (there's no way for a
> > machine client to distinguish between the two cases yet; I am hoping
> > for a VO-DML-based annotation there) have value=""; the rationale is
> > that PARAM/@value is, in effect, TABLEDATA-encoded[1] and in TABLEDATA,
> > an empty string is always NULL since VOTable 1.3.
> > 
> > If, on the other hand, @value is non-empty, then this value should be
> > included in the query literally (or after parsing and
> > TABLEDATA-serialisation, which should end up with an equivalent
> > result).
> 
> Thanks.  This response makes perfect sense.  However, unless I'm
> missing something (possible - is there a bit of text you can point at?)
> it's not spelled out or even really suggested in the DataLink text.
> 
> I don't think I'm the only one to fail to divine this intent;
> Carlos Rodrigo responded (in a message which may show up on-list
> at some point) that he thought that non-blank @value represented
> a default.
> 
> Also, some of the examples look a bit weird to me in the light of your
> interpretation.  For instance, section 4.3 has this:
> 
>    <PARAM name="COLLECTION" datatype="char" arraysize="*" value="ALL">
>      <VALUES>
>        <OPTION value="ALL" />
>        <OPTION value="FOO" />
>        <OPTION value="BAR" />
>      </VALUES>
>    </PARAM>
> 
> I don't understand the point of specifying all the options if the
> client is required to pass COLLECTION=ALL when invoking the service.
> Given your explanation, I would not in general expect a PARAM
> with a non-blank @value to have a VALUES child.

Right -- I eat my words, and this certainly goes to show that we need
to be more explicit.  As to wording (place TBD) I would propose:

  [something on @value="" meaning "pass something in"]  If a PARAM
  within the inputParams GROUP has a non-empty value attribute, a
  value must be passed to the corresponding service parameter.  While
  a client may optionally allow user interaction to change that
  parameter value, its default must be the value of the PARAM's
  value attribute.

That sounds almost like a parody.  Hm.  Improvements welcome, but
apart from surface form, I think that's sensible behaviour, and at
least the one I had in mind way back when.

One thing I'd consider given my implementation experience is whether
to disallow changing the parameter value absent a VALUES child of the
PARAM.  I think without VALUES it's hard to present an actually
usable UI in the first place, and, for instance, in the
datalink-for-one-dataset example, letting the user change the pubDID
is an invitation to produce breakage while not enabling any sort of
useful behaviour I could imagine.

But on the other hand, I expect we'll have a better design overall if
we keep all the information about what parameters are changable,
required, mutually exclusive, or whatever, to future VO-DML-based
annotation.

Hm.

         -- Markus