DALI1Dot1RFC < IVOA

IVOA Web>IvoaDAL>DALI1Dot1RFC (2017-05-11, PierreFernique)

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

Since it "defines the behaviour of common resources, the meaning and use of common parameters, success and error responses, and DAL service registration" (DALI abstract), DALI plays a special role in the Data Access Layer IVOA landscape.

This makes it unreasonable to require for direct full implementations to prove DALI take-up and interoperability. DALI components are embedded into other existing, or waiting to be approved, recommendations, and DALI behaviour is part of all recent DAL standards.

For this reason explicit DALI-1.1 reference implementation and validation tools are not reported here. Consider TAP, SIA, SODA documents to extract DALI recommendations and their clients and validators to review interoperability and validation.

Implementations Validators

(see above: Reference Interoperable Implementations)

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

These comments addressed in svn commit 3943

-- PatrickDowler - 2017-04-13

Comments from MarkTaylor

Sec 3.3: There is an issue with literal representations of numbers. Section 3.3.1 says "Real numbers must be represented in a manner consistent with the specification for double-precision numbers in XML Schema Datatypes (Biron and Malhotra, 2004)" , but the examples in e.g. sec 3.3.4 use Inf / -Inf to represent infinities rather than INF / -INF specified by XML-Schema part 2 (and DALI sec 3.1 says that parameter values are case-sensitive unless otherwise specified). In fact the problem is more complicated than that; I pointed this out with explanation and possible solution (use VOTable representations not XSD ones), seconded by Markus, on the DAL list on 16 May, see http://mail.ivoa.net/pipermail/dal/2016-May/007527.html, but I don't think any change has been made to the text in response to that concern. I note that this confusion has now been propagated from DALI to SODA sec 3.2.[345].
Sec 3.3.4: "The representation of an interval follows the array serialisation from VOTable." I'm not sure what is intended here. Possibly it's related to the previous point, or possibly not.
Sec 4.4.2: The first example contains a ERROR-valued QUERY_STATUS INFO followed by a TABLE element. That's probably permitted, but a bit misleading, since generally if an error has been identified up front, there will be no need to include a TABLE element. Remove the <TABLE>...</TABLE> from this example?
Sec 3.3.4: typo: "floating-pont" -> "floating-point"

As one of the document authors, I apologise for not pointing these out between PR publication and the calling of the RFC.

-- MarkTaylor - 2016-12-22

These comments are addressed in svn commit 3944

-- PatrickDowler - 2017-04-13

Comment on VOTable signature (mail thread raised)

The mail thread starting at http://wiki.ivoa.net/pipermail/dal/2017-March/007648.html makes a point on IVOA VOTable signature issue. Goal is to let clients more easily identify what kind of VOTables (SIA, SSA, ...) they're dealing with, so to handle them properly. Section 4.4.3 already has an answer to that, but it looks reasonable to raise from MAY to SHOULD the starting sentence of that section:

Additional INFO elements may be provided, e.g., to echo the input parameters back to the client in the query response (a useful feature for debugging or to self-document the query response), but clients should not depend on these.

Maybe adding also a footnote on the fact that IVOA identifiers are case insensitive and thus need to be compared with extra care.

-- MarcoMolinaro - 2017-03-31 (summarizing mail and f2f discussion)

This is addressed in svn commit 3945

-- PatrickDowler - 2017-04-13