[DataLink] access_url vs accessURL

[Patrick Dowler]

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

(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.


** 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.




-- 

Patrick Dowler
Canadian Astronomy Data Centre
National Research Council Canada
5071 West Saanich Road
Victoria, BC V9E 2E7

250-363-0044 (office) 250-363-0045 (fax)