param-link-to-field (was: Datalink data access services)

[Patrick Dowler]

I am finally getting into this and trying to see how these ideas fit in 
with the WD so I can put together a new (~complete) version. Here I am 
just trying to clarify some minor things, but I think I can see how it 
all fits together.

In this bit, the WD needs to define a general way to convey how to call 
a service with (some of) the parameter values coming from table columns 
in the result resource. In the simplest example, this would be used to 
refer to the {links} capability in the DataLink spec itself. In that 
capability, there is a single input parameter ID and the values come 
from a column in the results.

This part of the proposal is to change from using a GROUP with sibling 
PARAM and FIELDref to a PARAM with a child LINK. This does convey the 
same information, but the FIELDref has ref="datalinkID" while the LINK 
uses a fragment in value.

Is the ref in FIELDref explicitly defined to be an XML ID value in the 
document? Is a LINK value with a fragment explicitly an XML ID value? Or 
are one or both just conventions we are adopting?

Is there any particular significance *right now* to the 
content-role="ddl:id-source"?  Is this to allow for other LINK(s) in 
there that are not so marked? Is this to enable some semantic magic?

We are talking about a set of PARAM elements inside a RESOURCE with 
type="service" ... are there any other types of PARAMs than input? Are 
we intending to allow someone to describe the output parameters of the 
service as well? If not, do we really need the GROUP of input params?


Pat

PS-More questions on Markus' proposals to come. Let's keep this thread 
focused on this specific param-linking-to-field issue.

On 12/12/13 05:04 AM, Markus Demleitner wrote:
>    To enable the client to decide which column of the discovery result
>    table contains the appropriate identifier, the PARAM element describing
>    the ID parameter MUST contain one LINK element with
>    content_role="ddl:id-source", the value of which is a relative URI to
>    the FIELD element in the discovery result table (i.e., its id preceded
>    by a hash).
>
>    For instance, if a result of an ObsCore query could contain
>
>      <FIELD name="obs_publisher_did" ID="datalinkID"
>        utype="obscore:Curation.PublisherDID"
>        ucd="meta.ref.url;meta.curation"
>        xtype="adql:VARCHAR" datatype="char" arraysize="256*" />
>
>    A data access service accepting identifiers from the corresponding
>    column would declare its ID parameter in the inputParams GROUP like
>    this:
>
>      <PARAM name="ID" arraysize="*" datatype="char" ucd="meta.id;meta.main"
>        value="">
>         <DESCRIPTION>The pubisher DID of the dataset of interest</DESCRIPTION>
>         <LINK content-role="ddl:id-source" value="#datalinkID"/>
>      </PARAM>
>
>    The ID value datalinkID is of course arbitrary.

-- 

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)