[DataLink] access_url vs accessURL

[François Bonnarel]

Le 16/09/2014 23:22, Patrick Dowler a écrit :
>
>
> On 16/09/14 01:32 AM, Markus Demleitner wrote:
>
>>> ** smallish side issue: we should make it clear that an inut
>>> parameter reference to a FIELD also could refer to a PARAM with a
>>> constant value. That is how a prvider would handle something like
>>> RUNID without cluttering the {links} table. It is probably implied by
>>> the original use/meaning of PARAM, but that should be clarified too.
>>
>> Hm -- let me make sure I understand what you're talking about here.
>> Is this where there's a service descriptor in a DAL response rather
>> than in a datalink document?  What you're proposing is that I could
>> do (sketch)
>>
>> <VOTABLE>
>>    ...
>> <RESOURCE type"results">
>>      ...
>> <PARAM id="runid".../>
>> <FIELD id="pubdid".../>
>>
>> <RESOURCE utype="adhoc:service"...>
>>      ...
>> <GROUP name="inputParams">
>> <PARAM name="ID" ref="pubdid".../>
>> <PARAM name="RUNID" ref=runid".../>
>>
>> So -- you'd allow more than one PARAM in inputParams to be ref'ed,
>> rather than just ID?
>
> Yes, I had always thought of it as multiple input params could ref 
> content elsewhere.  The RUNID case was only one I had thought of, and 
> that one could probably be handled by embedding the RUNID into the 
> accessURL (because the RUNID is probably a constant in that document 
> and -- importantly -- the resulting URL would still be a resource 
> implementing the standardID)... that might be a little subtle :-)
>
> In some system, they could have multi-column keys (uugh) because they 
> haven't seen the light of URIs :-)
>
> Another one I thought of is that a table could have index values into 
> a grid and you could call some service with grid coordinates 
> (x=5&y=3). This is more something one might have in a TAP or SimDAL 
> result...
>
>
>> I've not thought that through, but I'm slightly worried because that
>> puts some additional load on client implementors.  So -- is there an
>> actual use case for this apart from RUNID?  I could see some
>> contrived cases where it might make sense to pass additional stuff
>> from result rows in, but I'm not convinced these justify introducing
>> a feature that will probably only be rarely used, so a
>> misimplementation might go undetected  for a long time, resulting in
>> interoperability problems.
>>
>> Anyway: If that's what you want, I personally could certainly live
>> with it. But then text needs to be added that clients *MUST* look for
>> ref in all PARAMs and  pass these accordingly; then, a validator
>> (*bambi eyes all around*) could exercise a client against that
>> feature and flag it invalid if it's not properly implemented.
>
> Yes, I think it is important to not limit to one input param with a 
> ref attribute so will keep that.
>

I personnaly agree with Pat on that point this is an important feature

Best regards
François
> thanks,
>