WD-DataLink-20140228

[Laurent MICHEL]

Hello,

Below are a few comments and suggestions for the draft.

1 INTRODUCTION:
---------------
It would be nice to specify that the scope of
Datalink goes beyond the VO. I suggest to end the introduction with
"Datalink is a protocol at the edge of the VO. It is designed to support 
resources in or out of its sphere."
That would also give an opportunity to reference the note 
http://www.ivoa.net/documents/Notes/DataLink/20130502/NOTE-DataLinkProposal-1.0-20130502.pdf 
(Mays 2014)

1.2.5 Free or Custom Service:
----------------------------
Adding an example:
"Custom services could do some processing (e.g. raw spectrum fitting) 
using parameters which must be specified within the Datalink response."

1.2.7 Recursive DataLink:
--------------------------
Is that an example or rather a feature which should be detailed 
somewhere in the section 4? In any case this should be mentioned in 4

2.1.1 Request:
---------------
"Service implementers may accept other values for this parameter...."
This assumption is always true isn't it? It can be removed since  the 
document does say anything else about these others values.

2.1.2 Response Format
---------------------
The [custom] word in the sentence "The custom mime type parameter 
defined below...is chosen to not...." is not clear. Mention something 
like "the mime type denoting a Datalink response (see3.1) is chosen to 
not...."

3.2 List of links
------------------
Most of columns are not required. Butb does it make sense to have an 
access URL with content_type? I think that content_type or service_def 
should be mandatory when there is no error but an access_url.

3.2.4 Service_def (yellow square)
---------------------------------
The content of the access_url is specific to one query response whereas 
the content of the accessURL is related to the service. That was why our 
custom service demos worked (may 2014) in 2 steps, considering only a 
service_def attached to one response and searched by a specific query.
My proposition to sort this out is add a new capability e.g. {deflinks} 
which returns a service_def for one specific ID. This service_def would 
be the same as this of the response. This way, both definition are bind 
through the VOSI response.
The standard could require that all parameters in accessURL must also be 
in the {deflinks} response.
This must be related to 4.1

3.2.6 Semantics
----------------
I strongly agree with a short list.
(yellow square) I think that the semantic field should refer to the 
nature of what is pointed by the link. It should not refer to the links 
itself.
Can we say that there is no semantic attached to the concept of link, 
that a link is just a generic entity binding 2 dataset?

3.3.1 VOTable output
----------------------
(yellow square) It is always better to put UCD on column descriptions,, 
there no need here for it since the quantities defined in 3.2 are not 
supposed to used in another context.

3.4 Error
---------
I strongly agree with a short list.

4.1 Service Resource
---------------------
(yellow square) A service description is neither data nor metadata. I 
think that a new type value would be welcome "service" is my candidate.

Showing an example here would be nice

4.3 Example
-----------
The example posted by Françoid on the list a couple of weeks ago would 
be good.

Bye Laurent

-- 
---- Laurent MICHEL              Tel  (33 0) 3 68 85 24 37
      Observatoire de Strasbourg  Fax  (33 0) 3 68 85 24 32
      11 Rue de l'Universite      Mail laurent.michel at astro.unistra.fr
      67000 Strasbourg (France)   Web  http://astro.u-strasbg.fr/~michel
---