DataLink RFC period annoucment

[Pierre Fernique]

Hi DAL, hi Markus,

Le 21/07/2014 10:12, Markus Demleitner a écrit :
> 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?
I just cite the first sentence in the introduction "/DataLink defines 
two distinct but related data-linking mechanisms/" (well mechanisms... 
methods...) : "/service descriptor resource/" and "/links/".  And after 
this introduction, it is not clear for me where and when we have to 
choose the first "mechanism", or the other one, or both.  May be a 
simple example could help the reader.
>
>
>> *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.

I have to say that I'm not a very keen supporter of the REST paradigm, 
but as the document seems to follow this recommendation (introduction 
page 5), and as VOSpace is RESTfull, it is surprising that the links to 
the REST servers will be not supported "natively" by the protocol. And 
in any case, a wrapper is generally a "last resort" solution, rarely 
implement directly on the server side, and very badly maintained in the 
long term (my experience).

More generally, as I partially said, the GROUP mechanism does not take 
into account any variable URL prefix (before the '?'), nor HTTP 
parameters without any value (flags) or combination of values in the 
same parameter. It will be a potential issue.

A few existing URLs possibly used in a datalink response for which the 
GROUP mechanism won't work (*red *fields)...

1) any VOSpace URLs
2) Dedicated "static" HTTP trees

  * http://www.cadc.hia.nrc.gc.ca/data/pub/*HSTCA*/*u21x0102t_prev.jpg*
  * http://alasky.u-strasbg.fr/*SDSS/DR9/color*/*Moc.fits*

3) A lots of cone search servers :

  * http://www.cadc-ccda.hia-iha.nrc-cnrc.gc.ca/sia/*CFHT*/query?POS=*83.633083,22.0145*&SIZE=0.2333&FORMAT=image/fits&VERB=2
  * http://wfaudata.roe.ac.uk/*ukidssdr9*-siap/?POS=*83.633083,22.0145*&SIZE=0.233&FORMAT=image/fits
  * http://vo.imcce.fr/webservices/skybot/skybotconesearch_query.php?&-ra=83.633083&-dec=22.0145&-size=*28.0,28.0*&-mime=votable&-out=basic&-loc=500&-search=Asteroids+and+Planets&-filter=*120+arcsec*

4) Dedicated services:

  * http://alasky.u-strasbg.fr/footprints/cats/vizier/*B/DENIS*?product=MOC&nside=512

5) TAP services :

  * http://geadev.esac.esa.int/tap-dev/tap/run/tap/sync?REQUEST=doQuery&LANG=ADQL-2.0&QUERY=SELECT+TOP+*1000*+*+FROM+*gums.mw*+WHERE+1%3DCONTAINS%28POINT%28%27ICRS%27%2C+alpha%2C+delta%29%2C+CIRCLE%28%27ICRS%27%2C+*80.89417*%2C+*-69.75611*%2C+*0.2333*+%29%29



>> 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.
I  totally agree that HTTP parameter with empty string is rare, but 
mainly because, in this case, the parameter is just fully removed 
("&param=" is removed). I suggested to be able to support this common case.

http://masthla.stsci.edu/hla/Footprints/aptfootprint/Footprints.svc/Footprints?POS=83.633083,22.0145&SIZE=0.4666666666666667,0.4666666666666667&*INST=*&LEVEL=Best



>
>
>> *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.
That's the point. Also, the client can have HTTP API which does not 
provide easy access to the HTTP header fields.
>
> 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>
Sounds good.

Cheers,
Pierre

>
> (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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.ivoa.net/pipermail/dal/attachments/20140721/66b85561/attachment.html>