DataLink: access_url vs accessURL

[Patrick Dowler]

Context: client calls datalink service with some ID, gets back a table 
of links; some of the links are to a service which needs some parameters 
(in our case, the data access service).

In the table of links, there is an access_url (specific to that link). 
If there is a service_def reference to a resource describing a service,
that thing has an accessURL as well. If it is a standard and/or 
registered service, that should be the base URL for the capability.

We have a scenario where the access_url in the table has the same base 
as the accessURL in the resource, but also has some extra parameters 
that are specific to that link (an archive file identifier) and an extra 
parameter for all those links (the RUNID either passed in to the 
datalink service or generated by it).

If table access_url == resource accessURL, then we need to add columns 
with XML IDs and refer to them with PARAMs in the inputParams group of 
the resource -- and the client *has to* construct the url correctly with 
those plus the extra client-specified params for the service being called.

Can/should we just embed these into the access_url in the table so the 
client only has to worry about the the meaningful params and not our 
internal workings? That seems like it should be OK, but it means that 
the table access_url != resource accessURL.

Just for fun, we implemented our current datalink service such that it 
embeds the RUNID but declares the "file ID" and makes the client do the 
work. Aside from clients not making any assumptions about how to append 
parameters to a url (always a good idea), it works.


I'm inclined to allow this as embedding those internal params is easier 
and avoids clouding the service description with opaque magic.
On the other hand, one could also say that a link row has a service_def 
or an access_url and not both, which would remove all ambiguity.

Another argument or access_url != accessURL would be that in some types 
of services one has to append path elements instead of parameters 
specific to the link. For example, the service could be VOSpace and the 
link could be to the node in VOSpace. The table access_url might be 
http://example.com/vopace/nodes/path/to/my/file and the resource 
accessURL would be http://example.com/vopace/nodes ({nodes} capability).

Now I'm really inclined to allow table access_url != resource accessURL. 
I think we have to allow it.

Thoughts?

-- 

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)