DataLink inputParam PARAM/@value

[Markus Demleitner]

Hi,

On Thu, Nov 23, 2017 at 03:11:45PM +0000, Mark Taylor wrote:
> >   [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.
> 
> I think that needs at least some changes.  The sentence:
> 
>     "If a PARAM within the inputParams GROUP has a non-empty
>      value attribute, a value must be passed to the corresponding
>      service parameter."

Oh, that would have to have been "*this* value must", but when
I wrote this I had totally forgotten about giving defaults to
user-changable parameters, which we've always wanted.  So, my text
doesn't work.

> doesn't look very helpful - surely the intention of *any* of the
> input params is that a value must, or at least is normally expected,
> to be passed to the corresponding service parameter.
> 
> In some library code I'm sketching out now that works out how to
> invoke Service Descriptor-defined services, I'm currently assigning
> input parameters into three different groups, according to how
> their values are acquired at service invocation time:
> 
>    - ROW parameters:
>          value is acquired from a cell of the result table;
>          a table row object must be supplied to obtain the value
> 
>    - FIXED parameters:
>         value is provided by the parameter definition
>         and fixed for all invocations
> 
>    - USER parameters:
>         the value must be supplied for each invocation by the user
> 
> I'm doing the grouping like this:
> 
>    if ( @ref not null )
>       -> ROW parameter
>    else if ( @value not null )
>       -> FIXED parameter
>    else
>       -> USER parameter

This looks like a useful distinction.  But the detection recipe
you're proposing has the obvious disadvantage that services cannot
give user-modifiable defaults, which, as said above, I've always
considered an important use case.  Well, except a few days ago.

> > 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
> 
> Not necessarily, some counter-examples might be:
> 
>    <PARAM name="give-me-all-columns" datatype="boolean" value="false"/>
> 
>    <PARAM name="MAXREC" datatype="int" value="100"/>

...fair enough; VALUES for a boolean are pretty much implied, and
MAXREC has uniform semantics independent of a concrete service.  So,
I retract the statement about the presence of VALUES being an almost
necessary condition for a useful parameter.

After the discussions of the last few days, I'd say that we're not
really ready to define a "don't change this" signature for Datalink
PARAMs.  I hence think the best we can do without an ugly hack is

    if ( @ref not null )
       -> ROW parameter
    else if ( @value not null )
       -> USER parameter with filled-out default  (probably mandatory)
    else
       -> USER parameter without filled-out default (probably optional)

Thoughts?

       -- Markus