DALI 1.2 Proposed Recommendation: Request for Comments

---

The changes in DALI-1.2 are primarily the inclusion of additional xtypes that can be used to add extra type information to columns (e.g. in VOTable, tap\_schema) and how such values are serialised. Also in this update: VOSI-availability is now optional as it is considered deprecated and is being removed from VOSI-next and OpenAPI components for some key DALI parameters are included in the specification. As always, various ambiguous statements have been clarified where needed.

Latest version of DALI-1.2 can be found at:

• https://www.ivoa.net/documents/DALI/20251024/index.html
• see also the GitHub repository for the latest change (since the RFC start)

Reference Interoperable Implementations

The prototype CAOM-2.5 TAP service at CADC (https://ws.cadc-ccda.hia-iha.nrc-cnrc.gc.ca/caom25/argus) makes use of the following xtypes (some from previous standards):

xtype	num_columns	standard
multishape	1	PR-DALI-1.2
timestamp	21
adql:REGION	1	see note
clob	1	see note
multiinterval	3	PR-DALI-1.2
point	1
uri	28	PR-DALI-1.2
shape	2	PR-DALI-1.2
uuid	14	PR-DALI-1.2
interval	10

query: select xtype, count(*) as num_columns from tap_schema.columns where xtype is not null group by xtype.
note: the adql:REGION value is still used for ivoa.ObsCore.s_region; the clob value is used for ivoa.ObsCore.access_url

The production CADC TAP service (CAOM-2.4) make use of some previously proposed/discussed xtype values and will be updated to DALI-1.2 in the near future.

Implementation Validators

TOPCAT/STILTS: Validator and implementation updates to cover all DALI 1.2 xtypes as appropriate, available in unreleased version at http://www.star.bristol.ac.uk/mbt/releases/topcat/pre/topcat-full_dali12.jar:

• Validation:
  • taplint new stage TYP checks that column metadata is consistent with xtype declarations (e.g. xtype="interval" columns have arraysize="2").
  • votlint/taplint checks VOTable column content is consistent with xtype declarations (e.g. xtype="uuid" values match xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx).
• Implementation:
  • Topcat shape plotting upgraded to recognise new DALI xtypes range, shape, multishape, moc.

---

Comments from the IVOA Community during RFC/TCG review period: 2025-11-05 - 2025-12-17

The comments from the TCG members during the RFC/TCG review should be included in the next section.

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.

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 TCG member during the RFC/TCG Review Period: 2025-11-05 - 2025-12-17

WG chairs or vice chairs must read the Document, provide comments if any (including on topics not directly linked to the Group matters) or indicate that they have no comment.

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

TCG Chair & Vice Chair

Applications Working Group

Section 2 - End Points: "A VOSI-capabilities endpoint is required for services registered in the IVOA registry system; the VOSI-capabilities endpoint is optional for services that are not registered or only included as auxiliary capabilities (e.g. of a data collection resource)." - Why does it have to be optional? Services either use the VO Architecture to which VOSI, which requires `capabilities` end point, is central or they don't but they are not VO Services. The `\capabilities` endpoint seems to be fundamental to interoperability in VO.

xtypes:

moc - should this be moc-2.0 or similar to allow for future versions of moc to be added later as the document states

shape - is this required? Can shape and multishape be merged into one xtype, i.e, shape but with the properties of multishape?

multishape - this is more an observation: this only supports union operations, so more complex shapes such as polygons with holes for example, would need to be redifned and expressed as union of polygons.

Why only 3 parameters have OpenAPI specs?

Data Access Layer Working Group

Data Model Working Group

Distributed Services & Protocols Working Group

Registry Working Group

Semantics Working Group

Data Curation & Preservation Interest Group

Education Interest Group

High Energy Interest Group

Knowledge Discovery Interest Group

Operations Interest Group

Radio Astronomy Interest Group

Spotted a few remaining typos:

In section 2.3, first sentenced "is always accessed as a using the name". Should that be "is always accesed using the name"?

In section 2.4: "If the VOSI-availability endpoint implemented a description of this capability must be provided" should that be "If the VOSI-availability endpoint is implemented a description of this capability must be provided"?

Otherwise I see no issues from a Radio IG perspective.

Solar System Interest Group

Time Domain Interest Group

Standards and Processes Committee

---

TCG Vote : 2025-12-18 - 2026-01-08

If you have minor comments (typos) on the last version of the document please indicate it in the Comments column of the table and post them in the TCG comments section above with the date.

Group	Yes	No	Abstain	Comments
TCG
Apps
DAL
DM
DSP
Registry
Semantics
DCP
Edu
KDIG
Ops
Radio	Yes
SSIG
TD
StdProc

---