<div dir="ltr">Hi Mark, all,<div>you may be right, and I may be confused by my</div><div>biased idea that datalink is meant to having</div><div>proper ID's in the originating discovery response</div><div>data table to attach to.</div><div><br></div><div>Thus, that would really mean two separate</div><div>datalink consumers for a client app, one for</div><div>services described directly in the discovery</div><div>response (your case 2) and one for the </div><div>links-response solutions (case 1).</div><div><br></div><div>I'm wondering, however, if also in case 1</div><div>there's a way to allow the adhoc:service </div><div>on a per row basis.</div><div><br></div><div>Cheers,</div><div> Marco</div><div><div class="gmail_extra"><br><div class="gmail_quote">2018-02-05 11:48 GMT+01:00 Mark Taylor <span dir="ltr"><<a href="mailto:m.b.taylor@bristol.ac.uk" target="_blank">m.b.taylor@bristol.ac.uk</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Marco,<br>
<br>
thanks for your response.<br>
<span class=""><br>
On Sun, 4 Feb 2018, Marco Molinaro wrote:<br>
<br>
> > Section 4 of the DataLink document describes Service Descriptors.<br>
> > These are RESOURCE elements in VOTable documents containing<br>
> > information about external services that can be invoked in<br>
> > a way that is relevant to the data in a results table contained<br>
> > within the same VOTable document.<br>
> ><br>
> > As I understand it, there are two separate ways these service<br>
> > descriptors can be used.<br>
> ><br>
> > 1. A {links}-response table (as described in DataLink section 3)<br>
> > may refer to a specific Service Descriptor by giving its ID<br>
> > in the service_def column.<br>
> ><br>
> > 2. Any VOTable is allowed to include Service Descriptor resources,<br>
> > as made explicit in paragraphs 2 and 3 of DataLink section 4.<br>
> > Such service descriptors will presumably have at least some<br>
> > input parameters that take their values from the results table.<br>
> ><br>
> > In case 2, the service descriptor effectively defines a different<br>
> > (full or partial) service invocation for every row of the results table.<br>
> > In case 1 however, such invocations are only defined for those rows<br>
> > in which the service_def column names the descriptor in question.<br>
> ><br>
><br>
> I agree, but I would say that your description of case 2<br>
> may fail if no DatasetID is set in a row. But that's probably<br>
> a borderline case.<br>
<br>
</span>Is that right? Section 4 says this:<br>
<br>
"Here we describe how to construct a resource that describes a<br>
service and add it to a VOTable document. The mechanism is<br>
general and can be used wherever a VOTable document is created."<br>
<br>
>From that I take that this mechanism is not tied to the {links}-response<br>
format or to provision of a DatasetID. So for instance you could<br>
write a VOTable that defines a Cone Search invocation for each row,<br>
like this:<br>
<br>
<VOTABLE><br>
<RESOURCE type="results"><br>
<TABLE><br>
<FIELD name="RAJ2000" datatype="double" ID="col_ra"/><br>
<FIELD name="DEJ2000" datatype="double" ID="col_dec"/><br>
<DATA><br>
<TABLEDATA><br>
<TR><TD>83.50</TD><TD>22.01</<wbr>TD></TR><br>
<TR><TD>323.25</TD><TD>-0.81</<wbr>TD></TR><br>
</TABLEDATA><br>
</DATA><br>
</TABLE><br>
</RESOURCE><br>
<RESOURCE type="meta" utype="adhoc:service"><br>
<PARAM name="standardID" datatype="char" arraysize="*"<br>
value="ivo://<a href="http://ivoa.net/std/ConeSearch" rel="noreferrer" target="_blank">ivoa.net/std/<wbr>ConeSearch</a>"/><br>
<PARAM name="accessURL" datatype="char" arraysize="*"<br>
value="<a href="http://cda.harvard.edu/cxcscs/coneSearch" rel="noreferrer" target="_blank">http://cda.harvard.edu/<wbr>cxcscs/coneSearch</a>"/><br>
<GROUP name="inputParams"><br>
<PARAM name="RA" datatype="char" arraysize="*" value="" ref="col_ra"/><br>
<PARAM name="DEC" datatype="char" arraysize="*" value="" ref="col_dec"/><br>
<PARAM name="SR" datatype="char" arraysize="1" value="1"/><br>
</GROUP><br>
</RESOURCE><br>
</VOTABLE><br>
<br>
Or is that not the intention?<br>
<span class=""><br>
> The distinction between 1 and 2 being only on where the<br>
> service descriptor adhoc:service sits: directly on the<br>
> results of discovery, in a further (multi)-access enabling<br>
> document.<br>
<br>
</span>If the example above is correct use of the Service Descriptor<br>
construct, then the difference is greater: in case 2 the service<br>
descriptor(s) can be applied to all rows of the results table,<br>
but in case 1 only those rows with an appropriate service_def<br>
value define such invocations.<br>
<span class=""><br>
> * - happy you sent this email 'cause you forced him<br>
> into a deeper look in Datalnk<br>
<br>
</span>I'm pleased that I could bring a little joy into your life!<br>
<div class="HOEnZb"><div class="h5"><br>
Mark<br>
<br>
--<br>
Mark Taylor Astronomical Programmer Physics, Bristol University, UK<br>
<a href="mailto:m.b.taylor@bris.ac.uk">m.b.taylor@bris.ac.uk</a> <a href="tel:%2B44-117-9288776" value="+441179288776">+44-117-9288776</a> <a href="http://www.star.bris.ac.uk/~mbt/" rel="noreferrer" target="_blank">http://www.star.bris.ac.uk/~<wbr>mbt/</a><br>
</div></div></blockquote></div><br></div></div></div>