DataLink RFC period annoucment

[Markus Demleitner]

Hi DAL,

On Fri, Jul 18, 2014 at 11:48:37AM +0200, Pierre Fernique wrote:
> *1) General comment:*
> Despite the introduction,  the difference between the two datalink
> methods has not be clear for me. Both are called "datalink" and it is
> difficult to understand the difference between the two methods with

I'm not quite sure what you mean by "two methods" -- standalone
datalink vs. service descriptor in DAL?  If so, I wouldn't call that
two methods, but we should obviously do a better job laying out how
things are supposed to work in both access scenarios.  Do you have
(possibly high-level) suggestions on how we could improve the text?


> *2) Technical questions:* Concerning the second method (with the
> PARAM definitions by GROUP):
> The possibilities opened by this method is very promising. At the
> first view, it seems simple and flexible, and very useful to build on
> the fly associated user forms.
> 
> a) However, I do not see how to describe REST links, or any URL for
> which the prefix depends of the parameter values. May be I'm wrong,
> but it seems that this method can only build URL on this template :
> http://static_url_prefix?param1=val1&param2=val2...
> However, it is quite common that some servers provide their
> collections on this basis URL template :
> http://host/variable_path/datasetID (VOSpace links ?). It would be
> great if basis URLs could be also described by this datalink method.

Hm.  I'm not wild about this -- much as I appreciate good-looking
URLs, I think allowing this is not going to make a better standard.
In particular, I'd claim that even if people actually ran such
services already, they'd have to write wrapper code anyway in order
to make it datalink compliant.  That wrapper code would have to do
the conversion from IVOID (which *should* be what's passed in through
ID) to their local datasetID, and then going from HTTP parameter to
URL part should be straightforward (i.e., of the order of two lines
of code).  I don't think a complication of the standard is warrented
there.

> c) One point concerning "blank or missing value". In my experience,
> some  servers have no ALL option for such or such parameter : just
> the lack of the HTTP "param=xxx" parameter meaning "ALL" for this
> constraint. Removing the "&param=" parameter of the URL in case of
> blank or missing value can be a solution for managing these cases.

What you're saying is that we should say, at some suitable point:

  Parameters not used in a service invocation should not be passed at
  all, rather than with empty values.

I'd somewhat have expected that to be implied -- do you really think
people would pass what in effect are empty strings?  I'm not opposed
to the prose, just a bit surprised that it might be necessary.


> *3) My wish. *
> In IVOA we use frequently VOTable as a container (SIA, SSA, TAP,
> ObsTAP, and now Datalink), but without magic code or any signature to
> recognize that this VOTable is a Datalink result, or a TAP result or
> whatever. And concretely it is a nightmare for client which are
> supporting  simultaneously several of these protocols. I recommend to
> introduce in our VOTable protocols (at least the new protocols) a
> signature which could be a simple INFO tag (ex: <INFO name="protocol"
> value="datalink1.0"/>).

Although I'm always a bit nervous when we put in the same information
in two places (in this case, the content-type header of the HTTP
response and then later the HTTP payload) I think I like that a lot,
mostly because I expect people might store datalink responses and
re-use them later, when there's not HTTP header any more.

So, I'd say we should have a new subsection in Sect 3 (I'd say it
should become 3.2, but if people are worried about renumbering
subsections at this late stage, 3.5 would be ok with me, too):

  3.2 Protocol declaration

  To help clients dispatch between various internal recipients of
  VOTables even in the absence of HTTP header information, datalink
  responses serialised in VOTables MUST contain an INFO element with
  a name SERVICE_PROTOCOL and a content of "datalink" as an immediate
  child of the VOTable element; the strings are interpreted
  case-sensitively  Services SHOULD declare the version of this document
  they conform to in the value attribute of the INFO element.

  VOTable responses from datalink 1.0 services would thus contain:

    <INFO name="SERVICE_PROTOCOL" value="1.0">datalink</INFO>

(This is fashioned after SSAP) What does everyone think?  Should
something like this get into VOSI?  The "dispatch according to
content"-thing appears to be something quite frequent, and offering a
general, non-heuristic method to do it sounds like good sense to me.

Cheers,

           Markus