DALI-1.1 Proposed Recommendation: Request for Comments

This is the RFC page for DALI-1.1. As per the abstract: DALI defines the base web service interface common to all Data Access Layer (DAL) services. This standard defines the behaviour of common resources, the meaning and use of common parameters, success and error responses, and DAL service registration. The goal of this specification is to define the common elements that are shared across DAL services in order to foster consistency across concrete DAL service specifications and to enable standard re-usable client and service implementations and libraries to be written and widely adopted.

Latest version of DALI-1.1 can be found at:

• http://www.ivoa.net/documents/DALI/

Reference Interoperable Implementations

(Indicate here the links to at least two Reference Interoperable Implementations)

Implementations Validators

(If any, indicate here the links to Implementations Validators)

RFC (including TCG) Review Period: 2016-12-05 - 2017-01-22

Comments from the IVOA Community during RFC period

In order to add a comment to the document, please edit this page and add your comment to the list below in the format used for the example (include your Wiki Name so that authors can contact you for further information). When the author(s) of the document have considered the comment, they will provide a response after the comment (please, copy/paste your signature with date to keep track of the review process).

Additional discussion about any of the comments or responses can be conducted on the WG mailing list. However, please be sure to enter your initial comments here for full consideration in any future revisions of this document

• Sample comment by WikiName
  • Response (by WikiName)

Comments from MarkusDemleitner

(1) p. 6 parenthetically mandates that the job must be "a child resource of the job list". Now, this is about as much as UWS 1.0 sect. 2.1.1 says ("The immediate children of the job list are the Job objects"). However, I can't really see a benefit of that constraint, and I can well see it lifted from UWS in some future version. If that happened, it would be unfortunate if DALI continued to require it. Can't we just remove the language here?

(2) The vocabulary URL still is an IVOID, which is bad in many respects -- see the DAL thread from May 2015, http://mail.ivoa.net/pipermail/dal/2015-May/007114.html (now that I re-read it: was that an invitation for me to change things?). I suggest we use http://ivoa.net/rdf/examples, and I volunteer to build the accompanying vocabulary.

(3) In the example for continuation (p. 12/13) I sugest the entire body of the "x" example should be replaced by an ellipsis on grounds that (a) it doesn't really contribute to illustrating continuation, (b) it looks like a TAP example, but TAP examples should be done differently (see TAP 1.1), (c) there's a TAP ivoid in there that's wrong for both TAP 1.0 and 1.1.

(4) sect. 2.6 says "The current VOSI-tables specification has some scalablity issues..." which may or may not be true for "current" depending on whether VOSI 1.1 or DALI 1.1 makes it to REC first. Hence, I'd suggest to strike the entire remaining paragraph.

(5) sect. 3.3.6 limits circle radii to 90 degrees. While I realise there are sane reasons for restricting circles to a half-sphere, this (at least) excludes what is a fairly common use case for cone search: Pulling a full catalog, for which the current idiom is RA=DEC=0, SR=180. I'm not saying that's a brilliant pattern or that future SCS specs should be using circle, but if we exclude this kind of thing, we should at least be aware of it.

(6) Sect. 3.4.5 says: "Services that implement UPLOAD must support http as a URI scheme (e.g., must support treating an http URI as a URL)". I believe the parenthesis should go, because (a) the distinction between URI and URL is (in effect) deprecated by RFC 3986, and (b) it doesn't really help constrain service behaviour. If you really think you need to specify what "support http URI scheme" means, I think it would need to be something like "retrieve the refeferenced resource" or somesuch, but I'd be surprised if anyone needed such a hint.

(7) p. 24: "Specific service specifications specify...and interpreted." -- that sentence is a bit too cute for my taste, and the ", and interpreted" ends a bit too sudden -- perhaps it can be rewritten slightly?

(8) Sect. 4, opening paragraph: it starts with "eventually results in one of three kinds" and then enumerates four different options. I believe the piece about redirects should be merged into the "eventually", perhaps like "...service requests, after possible HTTP redirects, eventually result...".

-- MarkusDemleitner - 2016-12-13

Comments from TCG members during the RFC period (same time span as above)

WG chairs or vice chairs must read the Document, provide comments if any and formally indicate if they approve or not the Standard.

IG chairs or vice chairs are also encouraged to do the same, althought their inputs are not compulsory.

TCG Chair & Vice Chair ( _Matthew Graham, Pat Dowler )

Applications Working Group ( _Pierre Fernique, Tom Donaldson )

Data Access Layer Working Group ( François Bonnarel, Marco Molinaro )

Data Model Working Group ( _Mark Cresitello-Dittmar, Laurent Michel )

Grid & Web Services Working Group ( Brian Major, Giuliano Taffoni )

Registry Working Group ( _Markus Demleitner, Theresa Dower )

Registry is happy with this.

-- MarkusDemleitner - 2016-12-13

Semantics Working Group ( _Mireille Louys, Alberto Accomazzi )

Data Curation & Preservation Interest Group ( Francoise Genova )

Education Interest Group ( _Massimo Ramella, Sudhanshu Barway )

Knowledge Discovery in Databases Interest Group ( Kai Polsterer )

Theory Interest Group ( _Carlos Rodrigo )

Time Domain Interest Group ( _John Swinbank, Dave Morris )

Operations ( _Tom McGlynn, Mark Taylor )

Standards and Processes Committee ( Françoise Genova )