Table Link questions

[Markus Demleitner]

Tom,

On Thu, Aug 13, 2015 at 12:26:10PM -0400, Tom McGlynn (NASA/GSFC Code 660.1) wrote:
> 1. When we return a data link response we often will have a product for
> which we have both a URL but which also has subproducts.  So we'd in
> principle like to fill in both the access_url and the service_def for this
> field.  Since the standard forbids that instead  we will return two rows.
> It would be nice to associate these to make it clear that these are
> effectively two representations of the same product.  Is that possible?
> Does the ID field do this?

The ID is constant for all rows pertaining to a given data product.
There is no way right now to "group" rows that are "more related"
than "to do with this dataset" (maybe "all calibration files" or so)
other than giving them identical semantics or use recursive datalink,
i.e., datalink links within datalink tables.

I personally would only do this if I had large amounts of ancillary
data that almost nobody is expected to look at.

> 2. The syntax of the service_def is completely unclear to me...  Is it
> intended that this is used in some way to specify the needed fields for a
> recursive call to the same table link service or is it to be substitute in
> values in the current table link service?  To clarify what I mean let me
> give  examples of two possible interpretations.
> 
> 
> An initial query response might include the following fragments.
> 
>    <VOTABLE> ...<FIELD ID='rowID' ...> <TR><TD>1234</TD>...</RESOURCE>
>        <RESOURCE type="meta" utype="adhoc:service">
>      ... <PARAM name="accessURL" ...value="http://xxx" />
>       ... <GROUP name="inputParams"><PARAM name=id ...ref="rowID"> ...

So, this is a table coming back from a DAL service, *not* a datalink
service, right?

> When I invoke   http://xxx?id=1234  I want to get two rows back (see the
> first question).  The first points to the URL for the observation,
> the second will request subproducts at the next level in the recursion.

Ok, this is the datalink call.

> These be given by the URL
>    http://xxx?id=1234&products=sub1,sub2,sub3

...and that's now a call to a custom service that just happens to
share its endpoint with a datalink service.

Did I get this right so far?

> Two possibilities from the documentation....
> 
>    <VOTABLE>... <FIELD="service_def"><FIELD="access_url">...
> <TR><TD/><TD>http://heasarc/obs/1234</td>..
> <TR><TD>id=1234&Products=sub1,sub2,sub3</TD><TD/>
>    </VOTABLE>

I don't quite get this one, I have to say.  But I guess this is meant
to be the reponse on the *datalink* endpoint, right?  If so, why
don't you just give the two URLs and be done with it?

> or
>    <VOTABLE>...<FIELD="service_def" ID="params"><FIELD="access_url">,,,
> <TR><TD/><TD>http://heasarc/obs/1234</td>..
> <TR><TD>id=1234&Products=sub1,sub2,sub3</TD><TD/>...
>        <RESOURCE type="meta" utype="adhoc:service">
>      ... <PARAM name="accessURL" ...value="http://xxx" />
>       ... <GROUP name="inputParams"><PARAM name=id ...ref="params"> ...
>       </VOTABLE>

These guys (with the adhoc:service utype and the PARAM ref) are for
embedding into the DAL requests, i.e., in the very first response,
before any datalink is talked.  They *point to* a datalink service,
they don't occur in their results.

> The former seems more natural, but there's no place where the syntax is
> defined --- especially if there are multiple parameters being used.
> The later is better defined but seems a bit clumsy.  The documentation of
> the table_def is opaque to me.
> 
> Is either of these close to what was intended?

If all you want is return two rows, you don't bother with service_def
in the datalink response at all -- just return the links with the
proper semantics.  Service_def only enters the picture if there's
actually some code that works with, at least effectively,
non-enumerated parameters (think cutout, where you certainly wouldn't
want to list all possible cutouts).

> 3. If I need to use multiple fields in the original VOTable to generate the
> link what is the ID field?  Is it just f1=v1&f2=v2 or
> v1,v2 or ....?    Or am I misconstruing the meaning of the ID entirely?

My original plan had been to require the full ID to be present in the
table.  But the current standard now lets you, in the adhoc:service
block, have as many PARAM ref="" things as you want and the client is
expected to collect those together.  So, you'd just add more PARAMs.

However, again, I suspect that's not the pattern you're looking for here.

> 4. Is it possible to use a <PARAM> instead of a <FIELD> as the thing
> referenced in the inputParams?  In practice this can probably be added into
> the accessURL instead, but if we could use PARAM's then the type="meta"
> RESOURCE could be exactly the same for all of our queries
> which would be nice.

I don't think the current standard says anything about that.  But
really, my answer would be: For robustness, don't play games and just
put constant elements into the accessURL.  There'll always be clients
that don't really expect PARAMs at the other end, and they're not
necessary either -- keeping constant parts of the accessURL in
VOTable PARAMs doesn't to me seem to help a lot with clarity,
robustness, separation of concerns, or anything else desirable.  Or
am I missing something?

Cheers,

          Markus