[DataLink] access_url vs accessURL

[Markus Demleitner]

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.

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

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.


Cheers,

         Markus