IVOA Recommendation: DALI: Data Access Layer Interface Version 1.0

This document describes the Data Access Layer Interface (DALI). 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.

💡 Research Summary

**
The IVOA Recommendation “DALI: Data Access Layer Interface Version 1.0” establishes a unified web‑service contract for all Data Access Layer (DAL) services in the Virtual Observatory. Its primary purpose is to define a common set of resources, parameters, response behaviours, error handling, and registration procedures so that disparate astronomical data services can be accessed in a consistent, interoperable manner.

The specification begins by delineating its scope and terminology, clarifying that DALI applies to any service that delivers astronomical data via HTTP, and that it builds on existing standards such as VOTable, ADQL, and the Universal Worker Service (UWS). Four core endpoints are mandated:

1. /sync – a synchronous service that returns the result in the same HTTP transaction.
2. /async – a UWS‑based asynchronous service that creates a job, returns a job identifier, and allows the client to poll the job’s phase, retrieve intermediate results, and finally download the completed output.
3. /capabilities – a VOTable document describing the service’s supported operations, output formats, and any special features.
4. /examples – a collection of ready‑made query examples to aid developers in constructing valid requests.

Standard parameters are defined for every DAL service. REQUEST specifies the operation to perform; LANG indicates the query language (e.g., ADQL, PQL); MAXREC caps the number of rows returned, protecting servers from runaway queries; and FORMAT selects the MIME type of the response (VOTable, CSV, FITS, etc.). All parameters must be URL‑encoded and are case‑sensitive. Service‑specific parameters may be added, but they must not conflict with the standard set.

Response handling follows a strict pattern. Successful synchronous calls return HTTP 200 (OK) with the payload in the requested format. Asynchronous calls initially return HTTP 202 (Accepted) and a job URL. Clients monitor the job’s state via /async/{job-id}/phase, which yields values such as PENDING, EXECUTING, COMPLETED, or ERROR. When a job finishes, the results are available under /async/{job-id}/results. Errors are communicated using appropriate HTTP status codes (400, 401, 403, 404, 500, etc.) together with a VOTable INFO element containing QUERY_STATUS="ERROR" and a human‑readable ERROR message. This dual channel (HTTP + VOTable) enables both programmatic and user‑friendly error diagnostics.

Service registration is tightly integrated with the IVOA Registry. Providers must publish a VOResource record that includes a capability element with standardID="ivo://ivoa.net/std/DALI#1.0" and a description of the supported parameters, output formats, and any authentication requirements. This metadata allows client applications to discover DALI‑compliant services automatically and to verify compatibility before issuing queries.

Security considerations are left to the service implementer, but the standard strongly recommends HTTPS for all endpoints and permits the use of the Authorization header for token‑based or API‑key authentication. No specific authentication scheme is mandated, preserving flexibility for public data services as well as restricted archives.

Versioning is handled via the standardID and a version attribute. DALI 1.0 is designed to be backward compatible with future releases; clients that understand only version 1.0 can still interact with a version 2.0 service as long as the service continues to expose the required 1.0 resources and parameters.

In summary, DALI 1.0 provides a comprehensive, technology‑agnostic blueprint for building and consuming astronomical data services. By standardising endpoint structures, query parameters, response formats, error reporting, and registry metadata, it dramatically reduces the effort required to develop reusable client libraries and to integrate heterogeneous data archives into scientific workflows. The result is a more cohesive Virtual Observatory ecosystem where data discovery, access, and analysis can be performed with a single, well‑defined set of protocols.