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
clob	1	see note
multiinterval	3	PR-DALI-1.2
point	1
uri	28	PR-DALI-1.2
shape	3	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 was used for ivoa.ObsCore.s_region but this has been updated to use shape in this prototype; 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
answer: the MOC reference is limited to a specific version of MOC on the advice of the authors because an xtype has to define a specific serialization. It is true that if MOC-2.1 existed and the text of the appropriate section was the same that someone could read that standard and do the right thing... but there is also no way stable way to refer to a specific section of a standard across versions. Maybe the mention of section 4.3.2 explicitly is an editorial mistake, but I recall that more general language was easy to misinterpret given the content of the MOC standard. -- PatrickDowler 2026-02-12

shape - is this required? Can shape and multishape be merged into one xtype, i.e, shape but with the properties of multishape?
answer: Combining shape and multishape was deemed a poor design because they are two different concepts with very different implementation complexity: shape is polymorphic and multishape is a collection. If we combine these, then any service declaring support for "shape" has to support the whole thing. -- PatrickDowler 2026-02-12

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 redefined and expressed as union of polygons.
answer: Yes, the syntax of multishape directly means union. This design was driven by balancing use cases and complexity and it was deemed that (fully general) holes in arbitrary shapes is not needed for the vast majority of use cases. The one we did consider is mosaic camera data: in principle there may be gaps between detectors that could be describes as small holes in the shape, or a detector could fail to read and leave a larger hole in the overall shape. We expect that one would just include a shape (rectangle) for each detector and that would naturally convey to the user the right information (note that the previous limitation that shapes in a multishape cannot overlap was removed). Yes, you cannot have a circular hole in a shape without considerable effort reformulating that as a number of polygons. Again, balancing use case coverage and complexity. -- PatrickDowler 2026-02-12

Why only 3 parameters have OpenAPI specs?
answer: Of the 6 standard parameters, two are more or less obsolete (request and version) and one is rarely used and (in my opinion) kind of useless (runid). The 3 parameters that do have OpenAPI descriptions are the 3 that are actively used. -- PatrickDowler 2026-02-12

Data Access Layer Working Group

• DALI now defines datatypes and xtypes. This is one major feature of DALI. I think that deserves to be mentioned in the Abstract (3rd sentence starting with "This standard defines ...") and in the Introduction (1st sentence).
  
  

• Section 2.1:

  • If a DALI-async is always a UWS service, we should probably give its capability identifier, isn't it?
    ivo://ivoa.net/std/UWS#rest-1.1 (although other versions of UWS are accepted too)
    
    

  • "or it may add additional parameters by a POST to the current list of parameters"
    • According to UWS (cf UWS-1.1, section 2.1.11. Parameter List), parameters can not be added after job creation. Maybe it would be nice to indicate that modification with POST is possible only for pending jobs.
      
      
  • "DALI-async enpoints may provide other ways to interact with jobs as specified in current or future UWS specification"
    • What does it mean?
      
      
• Section 2.2:
  
  
  • "A synchronous job is created by a GET or POST request to a synchronous job list,"
    • May I suggest to rename "synchronous job list" into "endpoint"? It is strange to speak about a job list when no list can be returned, unless if I have not well understood this part.
      
      
• Section 2.3.4:
  
  
  • "a resource attribute with an empty value (referring to the current document)"
    • In the example for the continuation property, there is no empty resource attribute while it is supposed to be mandatory according to the text. Is it normal?
      
      
• Section 2.4:
  
  
  • "If the VOSI-availability endpoint implemented a description of this ca- pability must be provided"
    • Missing is between endpoint and implemented


• Section 2.5:
  
  
  • "In DAL services, this endpoint always accessed under the name "capabilities"."
    • Missing is between always and accessed


• Section 3:
  
  
  • "We define some general purpose values for the xtype attribute of the VOTable FIELD and PARAM elements for simple structured values: timestamp, interval, hms, dms, point, circle, range, polygon, moc, shape, multishape, uri, and uuid (see below)."
    • It may be better for future updates of this document, to just give some examples. Thus, it won't be necessary to think of updating this list each time a new xtype is defined.
      
      
• Section 3.8, 3.9, 3.10:
  
  
  • 3.8: "These are specified using a custom interpretation of the MAX child element with a value that is the largest circle that makes sense for the operation"
  • 3.9: "These are specified using a custom interpretation of the MAX child element with a value that is the largest range that makes sense for the operation"
  • 3.10: "These are specified using a custom interpretation of the MAX child element with a value that is the largest polygon that makes sense for the operation."
    
    
  • What would the MAX element describe? For instance for a circle, is it the maximum radius, the maximum coordinates? Both? Would it be possible to have at least one example in DALI-1.2?
  • Maybe an additional sub-section that would describe the expected value for MAX for all the geometries?
  • An additional question would be: is it possible to describe the maximum value of a circle with a polygon to specify what particular sky region is covered?
    
    
• Section 3.9:
  
  
  • "A range is a coordinate bounding box"
    • I don't remember if there were discussion about this, but I have some vocabulary issue concerning interval and range, especially while using Postgres. With this latter, range is actually what Postgres defines as interval, while interval is a special type used to manipulate time (to add or subtract an interval of time to a date/time) in Postgres. It is then quite strange to see range in DALI used to define a geometry. It is too late to change interval and in some way, its name really conveys its usage (so, no problem with it), but would it be possible to change the name range into something that does not really mean interval and that would convey more the idea of geometry. Some naive suggestions: coordbox, coordrange, coordinterval, ...
      
      
• Section 3.11:
  
  
  • "may be a one- or two-dimension (spatial) MOC."
    • What does mean "a two-dimension (spatial) MOC"? ST-MOC for instance? However, the first sentence of this sub-section speaks about Spatial MOC and the following note explicitly says that T-MOC and ST-MOC may be added later. In brief, this sentence is a bit vague/enigmatic. Does that mean we can put also ST-MOC in there although the xtype may be imprecise?
      
      
• Section 3.12:
  
  
  • In the second example for shape, is it normal that blanks are visible with weird UTF-8 characters in the PDF version for the example for the MAX parameter in VOTable for shape?
    
    
• Section 4.1:
  
  
  • "Parameter names are not case sensitive"
    • On the contrary to what DALI-1.2 requires, and according to discussions going on in, at least, these two GitHub Issues - DALI#21 and ObjObsSAP#22 - the parameter names should be case sensitive. This is particularly a constraint coming from OpenAPI. Considering the number of existing DAL standards and their implementations, DALI should not enforce a particular case-folding for existing standards, but must encourage new versions and new standards to use a particular case-folding. This choice may be left to the standard authors, knowing that most of the time, the upper-case seems to be used as it is the typographical choice in DAL standard documents that service implementors have followed while developing their service. I know this is quite a big change, but would it be possible to change the text in such direction: case-sensitive for new versions of DAL standards (or new standards) ; concrete DALI service specification would have the choice of the case folding to use, but DALI could recommend one.
      
      
• Section 4.3.1 and 4.3.6:
  
  
  • There is no OpenAPI snippet for the REQUEST and RUNID parameters. It seems normal for the VERSION parameter as it is deprecated. But for the two others, is it because they are optional? Although there are optional, they could be used in the future (I may think to REQUEST=doMOC in a possible usage of MOC in TAP/ADQL, for instance). Besides I think they are not very complicated to describe in OpenAPI.
    
    
• Section 4.3.4:
  
  
  • "must accept MAXREC parameters"
    • parameters -> parameter


• Section 5.4.3:
  
  
  • Would it be interesting to cite Data Origin - EN 1.2 as a good starting point for such additional useful metadata (now that it is officially endorsed)?

-- GregoryMantelet 2026-06-04

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"?

answer: Thanks - typos fixed in https://github.com/ivoa-std/DALI/pull/71

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

---