DataLink inputParam PARAM/@value

[François Bonnarel]

Hi all,

I think we have to take into account the various situations where we can 
encounter a service descriptor to fully encompass the problems and 
solutions.

     According to our specs (DataLink and SODA) we have 3 different 
types of services in service descriptors and three different types of 
occurence of these descriptors

       I ) service types

               a ) the DataLink {links} resource or service.

               b ) a SODA service, or another standard service

               c ) a custom service (non standard)


        II ) occurence types

                a ) a data discovery query response (ObstAP, SIAV2 but 
also SSA, SIAV1).

                b ) the DataLink {links} resource itself

                c ) any other service response (cone search, TAP in 
general, custom service "empty" response )

As long as service types are concerned, the a case should have a FIXED 
or ROW value for its unique Parameter (ID = )

                In  The b case there is a list of standard parameters 
and there values have to be user defined (USER) ,but constrained by 
dataset metadata

                In the c case we can imagine any combination. But USER 
can dominate

               For the occurence a case we can imagine ROW easily. 
Occurence b case will be more adapted to FIXED and USER. Occurence c) 
can be anything

       SODA DESCRIPTOR in a  data discovery query response or DataLink   
{links} resource is only a special case.

Cheers
François



Le 27/11/2017 à 13:00, Mark Taylor a écrit :
> On Thu, 23 Nov 2017, Markus Demleitner wrote:
>
>> Hi,
>>
>> On Thu, Nov 23, 2017 at 03:11:45PM +0000, Mark Taylor wrote:
>>> 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.
>>
>> ...
>>
>> 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)
> It's not much different from what I suggested, given the caveat from
> my message:
>
> On Thu, Nov 23, 2017 at 03:11:45PM +0000, Mark Taylor wrote:
>
>> This arrangement doesn't prevent the application code from filling
>> these parameters differently, e.g. giving the users the option to
>> change ROW or FIXED parameter values at invocation time; so the
>> ROW and FIXED values can be viewed as defaults.  I'm currently
> Except your formulation does sort of presuppose user interaction.
> At least one scenario I am expecting is a DataLink with all
> parameters filled out to give a fixed link URL for each row,
> and no expectation that the user needs to see or supplement
> the supplied values.  That would correspond to all ROW/FIXED
> in my terminology or all ROW/USER-with-filled-out-default in yours.
> But I think the only difference here is wording.
>
> --
> 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/