param-link-to-field

[Markus Demleitner]

Dear DAL,

On Tue, Feb 18, 2014 at 03:55:52PM +0100, François Bonnarel wrote:
> A simple "ref" on the SErvice parameter could work as long as it's
> distinguished  by an ad hoc (DataLink specific utype) this way, eg :
> ><RESOURCE type="service">
> ><PARAM name="resourceIdentifier" datatype="char" arraysize="*"
> >         value="ivo://example/datalink" />
> ><PARAM name="standardID" datatype="char" arraysize="*"
> >         value="ivo://ivoa.net/std/DataLink#links" />
> ><PARAM name="accessURL" datatype="char" arraysize="*"
> >         value="http://example.com/datalink/mylinks" />
> ><PARAM name="ID" utype="dl:serviceInputParam" ref="datalinkID" />
> ></RESOURCE>

Whoa!  I had completely forgotten about PARAM/@ref.  Sorry about
causing all the stir.  This is, to me, the VOTably correct solution.

While thinking a bit further, I wondered what the utype here said.
Giving the LINK a content-role would have made sense because the
PARAM might have had other LINKs.  In the PARAM, on the other hand,
the utype refers to the whole thing element (rather than just the
ref), and the PARAM with the name ID, already by the protocol
definition, must always be the parameter holding the identifier.  

If we now have a second thing to mark up "this is the id parameter"
-- i.e., the utype --, we'd have to say "a service that has
dl:serviceInputParam on anything but a PARAM with the name ID is
invalid," and then anyone would ask: "Then why bother with the utype
at all?"

After this, I'd like to retract the part of my Dec 12 proposal
between "A data access service accepting identifiers" and "is of
course arbitrary."  I'd like to replace it with:

  A data access service accepting identifiers from the corresponding
  column would declare its ID parameter in the inputParams GROUP with
  a ref attribute referencing the FIELD's ID.  Continuing the
  previous example, it could look like this:

    <PARAM name="ID" arraysize="*" datatype="char" ucd="meta.id;meta.main"
      value="" ref="datalinkID">
       <DESCRIPTION>The pubisher DID of the dataset of interest</DESCRIPTION>
    </PARAM>

  The string chosen for the FIELD's ID and consequently in the
  PARAM's ref attributes is up to the generating service (i.e.,
  clients must not assume the datalinkID).  The description of the
  PARAM should be adapted to the actual identifier used.

Again, apologies for having missed this elegant solution and
therefore having caused all the noise.  And thanks to François for
pointing this out.

Cheers,

       Markus