IVOA Recommendation: TAPRegExt: a VOResource Schema Extension for Describing TAP Services

This document describes an XML encoding standard for metadata about services implementing the table access protocol TAP [TAP], referred to as TAPRegExt. Instance documents are part of the service’s registry record or can be obtained from the service itself. They deliver information to both humans and software on the languages, output formats, and upload methods supported by the service, as well as data models implemented by the exposed tables, optional language features, and certain limits enforced by the service.

💡 Research Summary

The paper presents TAPRegExt, an IVOA‑approved XML schema extension that standardises the description of Table Access Protocol (TAP) services within the VOResource framework. TAP is the de‑facto protocol for querying astronomical tables, but individual TAP endpoints differ in the ADQL version they support, the output serialisations they can return, the ways they accept uploaded data, the data models they implement, optional language features, and operational limits such as maximum record counts or upload sizes. TAPRegExt provides a machine‑readable, interoperable way to capture all of these characteristics so that both human users and software agents can discover, evaluate, and interact with TAP services reliably.

The document first situates TAPRegExt within the broader VOResource model, explaining that a TAP service’s registry record contains a <capability> element whose standardID is set to “ivo://ivoa.net/std/TAP#regext”. By using xsi:type the extension introduces a concrete type (e.g., tr:TableAccess) that inherits all generic VOResource attributes while adding TAP‑specific children.

Key components of the schema are:

• language – Describes the query language(s) a service accepts. The current mandatory language is ADQL; the element records the ADQL version, a human‑readable name/description, supported user‑defined functions, parameter data types, and a list of optional features (e.g., async, sync, maxrec). Each feature is expressed as a <feature> sub‑element, allowing future extensions without breaking existing parsers.

• outputFormat – Enumerates the serialisation formats the service can return. For each format the schema captures the MIME type, an optional short alias, and a serialization attribute indicating whether the data are delivered as a VOTable, CSV, FITS binary table, etc. This enables client software to request a preferred format via the FORMAT query parameter and to validate that the service truly supports it.

• uploadMethod – Specifies the mechanisms by which a client may upload auxiliary tables for use in a query. The protocol attribute can take values such as inline, url, or ftp. This is directly linked to the TAP UPLOAD parameter, making it clear whether a service expects the data to be embedded in the request body or fetched from an external location.

• dataModel – Provides a URN that identifies the astronomical data model(s) implemented by the exposed tables (e.g., ObsCore 1.1, SimDB 2.0). By exposing this information, a client can automatically map table columns to well‑known semantic concepts, facilitating cross‑service data integration.

• limit – Conveys operational constraints: maxRecords (maximum rows per synchronous query), maxAsyncJobs (concurrent asynchronous jobs allowed), maxUploadSize (maximum size of uploaded tables), and similar caps. Clients can retrieve these limits before launching heavy queries, thereby avoiding unnecessary failures and enabling smarter workload planning.

Security considerations are addressed through the optional <securityMethod> element, which can reference standard IVOA authentication mechanisms (OAuth, SAML, OpenID, etc.) via their own standardID. This makes the authentication requirements of a TAP service discoverable at the registry level.

The schema also defines the service’s access URLs. Within the <interface> element, accessURL elements are provided for both synchronous (role="std") and asynchronous (role="async") endpoints, each annotated with the appropriate standardID. This dual‑endpoint model allows clients to choose the execution mode that best fits their workflow.

From an operational standpoint, TAPRegExt greatly simplifies registry queries. A client can issue a registry search such as “ADQL 2.0 capable services that return VOTable or CSV and support asynchronous execution”, and the registry engine can filter on the <language>, <outputFormat>, and <interface> elements to return a concise list of matching services. Moreover, automated client generators can ingest TAPRegExt metadata to produce language‑specific wrappers that handle parameter validation, query construction, and result parsing without manual coding.

The paper concludes that TAPRegExt fills a critical gap in the IVOA ecosystem by providing a comprehensive, extensible, and standards‑compliant description of TAP service capabilities. Its tight integration with VOResource ensures backward compatibility, while the use of XML schema features such as xsi:type and enumerated sub‑elements guarantees forward compatibility as new query languages, serialisations, or security protocols emerge. Consequently, TAPRegExt not only enhances discoverability and interoperability of existing TAP services but also future‑proofs the architecture for forthcoming extensions in the virtual observatory landscape.