[DataLink] access_url vs accessURL

[Patrick Dowler]

On 16/09/14 01:32 AM, Markus Demleitner wrote:
> Hi DAL,
>
> On Mon, Sep 15, 2014 at 01:20:26PM -0700, Patrick Dowler wrote:
>> ** 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
>
> I like it.  It also helps *very* simple-minded clients that will not
> try to access a service's base URL unadorned because they don't know
> about services.

Sounds good.

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

thanks,

-- 

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)