[DataLink] access_url vs accessURL

[François Bonnarel]

Hi all,
Le 15/09/2014 22:20, Patrick Dowler a écrit :
>
> Recap: In the {links} resource there is a column access_url with either:
>
> 1. a usable link (service_def == null)
>
> 2. a link to a service, but it needs more input (service_def refers to 
> a service descriptor resource that tells you about those extra input 
> parameters
>
> Nothing here effect the use of service descriptors per se: those are 
> well defined. Specifically, if the descriptor has a standardID, then 
> the accessURL *must* be the base URL to that capability.
>
> In the case of #2, the spec allows the access_url in the {links} to be 
> present when service_def != null and to be different from the base 
> accessURL in the referenced service descriptor. This is intended to be 
> convenient. Some examples:
>
> (i) the service embeds RUNID parameter in the access_url so it doesn't 
> need an extra FIELD/PARAM with RUNID values and an extra input param 
> in the service for RUNID... could be done rigourously but it seems 
> convenient to unclutter the {links} table and service descriptor
>
As far as I catch you, I think there is also   use cases where :
(i bis) the service  is parameter based and  you want to freeze some 
PARAM values (some not all) for a SUBSET of the DATASETS in the response
exempli gratia : your preview custom service gives potentially two 
FORMAT = HCOMP and JPEG. But actually you deliver HCOMP only if you get 
it stored. You don't provide it if uou have to compute it. So you have a 
service with several parameters but some time you want to attach an URL 
with FORMAT=JPEG only.
I have other use cases like this in mind where people would like to play 
with accessURL = root base URL, service descriptor describing all the 
params and access_url partially fixing some of them.
> (ii) the service is RESTful (eg vospace) so the provider constructs 
> the full path in the {links} table access_url and, as required, 
> describes the vospace {nodes} resource in the service (eg describes 
> the params to the node, like view, uri, limit, etc)... again, provider 
> doesn't need the cutter of a FIELD with "vos" URIs that wouldn't help 
> anyway since the values are not used as parameter values when calling 
> the {nodes} resource... (see folowup email about RESTful services)
>
>
>
> ** Proposed change: The simple way out is to say that in the {links} 
> table there is an access_url *or* a service_def, but not both. Then 
> all clients will use the access_url directly or construct a URL via 
> the service_def. Providers could still embed (opaque) params in the 
> accessURL, but the variable ones would have to be referred to and 
> pulled from wherever they are located. Consider this the "normalised" 
> solution with no redundant ways to do things; this should be the 
> preferred choice in a 1.0 spec.
>
OK, I see I will have to live with this one. The use case I had in mind 
(se above) can be managed by definng several service descriptors with 
the same fundamental set of Parameters. Less elegant but wil work

I agree with the proposed change

Best regards
François
>
> ** 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.
>
>
>
>