Table Link questions

[Tom McGlynn (NASA/GSFC Code 660.1)]

Looking at the new Table Link standard I think it holds a lot of promise 
in making it much easier to publish data using VO standards.  I'm 
looking to see if I can publish HEASARC data this way in the next month 
or two -- at least in some beta version.

I've got a couple of questions that I hope experts on the list can 
address.  First let me set the context...

The way HEASARC data products are structured is that for a given row in 
a table there is a hierarchical list of data products associated with 
the row.  [In fact there may be multiple hierarchies for a given row, 
but we can ignore that for the nonce.]  My naive plan is to use 
DataLinks to render this same hierarchy.  But I'm unable to fully 
understand from the standard document if and how I can do this.

For example the top level product might be the entire observation and 
typically would correspond to a directory on our web site.
At the next level there might be a Housekeeping, RawData, 
StandardProducts, and QuickLookProducts subproducts.  These
might correspond to subdirectories, sets of files or individual files.  
The standard products might then include an events file, image and 
spectrum, and so on.  It's not uncommon to have three or four levels in 
the hierarchy.

Questions:
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?

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"> ...


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.  
These be given by the URL
    http://xxx?id=1234&products=sub1,sub2,sub3
where the knowledge of which subproducts are appropriate is derived from 
the product hierarchy in our system -- it's
not something that is directly inferrable from the original table 
request alone.

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>

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>

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?

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?

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.


Many thanks for your insights.

     Regards,
     Tom McGlynn