Datalink Feedback III

[Markus Demleitner]

Dear DAL list,

I'm sure all of you have already waited impatiently of the third
installment of my bickering about the Datalink draft.  This
time, it's about the content of service_def, which currently is
either an IVORN (for a standard service) or an id of a RESOURCE
element within the VOTable.

For reasons of syntactic clarity, I'd much prefer if the reference to an
internal service in service_def always were a URI, even if we restrict
things to either IVORNs or pure fragments.

Hence, I'd like to replace the current Text of 3.2.4 service_def with:

  The service_def column contains a URI that indicates a service
  definition.  If service_def is not null, access_url points to a service
  that requires additional parameters to yield a useful result.
  The service_def column can contain a full IVORN to indicate a
  standard interface exposing data for the DID.

  The other allowed form of URI is a pure fragment part, identified by a
  leading hash character (#).  In that case, the datalink response
  document must contain a service resource as specified in section 4.  For
  instance, a service_def value of #srv1 would refer to a service
  definition of

    <RESOURCE type="metadata" ID="srv1" utype="adhoc:service">
    ...
    </RESOURCE>

  In this case, the access URL defined within the service RESOURCE MUST be
  the same as the access URL given in the table row.

  If service_def is NULL, the access_url may be used with no additional
  parameters or knowledge. It should be NULL even if access_url points to
  some resource generated on the fly if access_url is intended to be used
  as-is (e.g. direct download links or links to dynamic content where all
  parameters are already included in the link, such a on-the-fly preview
  generation).


A second issue (but related enough to IMO warrant inclusion in one
mail) in this connection is: Do we have a good idea already what
clients are supposed to do if there is an IVORN in service_def?  I
believe we would need to say something like:

  If service_def is an IVORN, the discovered id must be passed in
  using a method specified by the standard referenced.  For the
  legacy standards ivo://ivoa.net/std/ssa and ivo://ivoa.net/std/sia,
  this specification defines that the identifier must be passed in
  through the PUBDID parameter.  Only one value is allowed per
  service call.

I'm not sure I much like that myself (e.g., no creator DIDs allowed,
and SIAP doesn't even talk about a PUBDID parameter, so that would be
an extension), but I don't see how else IVORNs could be make useful
in service_def.

Cheers,

        Markus