Datalink Feedback III

[Patrick Dowler]

In the current WD< the service_def param is only allowed to be the 
fragment refering to a service description. The client has to go look at 
that service to find a standardID (if there is one).

Allowing a standardID in the service_def means there is no "local" 
service description and the client has to "know" that standard or lookup 
in a registry. It seems like a shortcut/optimisation to avoid having to 
provide/use the service description in the votable. Is that really going 
to help?

Pat

PS-I had actually been convinced that the service descriptions were the 
better way to go in all cases, which is why 3.2.4 is deceptively 
simple... but I think all the functionality is there.

PPS-I agree that some advice on how to link legacy services is a good 
idea, but if people just use the service decription they can tell 
clients exactly how to call them with the ivorn, even if a custom param.

On 25/03/14 12:59 AM, Markus Demleitner wrote:
> 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
>
>

-- 

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)