Clarification on ObsCore 1.1 Specification

[Markus Demleitner]

Hi Phelokazi,

On Thu, Oct 08, 2026 at 12:36:07PM +0000, Phelokazi Dube via dm wrote:
> I am currently working on implementing an ObsCore/ObsTAP service
> for the Southern African Large Telescope (SALT) at the South
> African Astronomical Observatory (SAAO), using DaCHS as our Virtual

[disclosure: main DaCHS developer speaking here]

> 1. pol_xel datatype — INTEGER or BIGINT?
> In Table 4 (TAP Implementation of ObsCoreDM), the datatype for
> pol_xel is specified as adql:BIGINT. However, the version change
> history indicates that the datatype was changed from BIGINT to
> INTEGER. Could you please confirm which datatype is intended for
> pol_xel?

DaCHS used to have bigint until a while ago
(<http://blog.g-vo.org/queries-against-my-obscore-are-slow-.html> has
a bit of background).  The hard-coded sizes have been a topic before
<http://mail.ivoa.net/pipermail/dm/2016-June/005408.html>, but then
somehow we failed to update the spec accordingly.

My take: We'll have string/integer types as in RegTAP
<https://ivoa.net/documents/RegTAP/20241002/REC-RegTAP-1.2.html#tth_sEc8>
in the next minor version, and hence you shouldn't need to worry.
Current (I think) versions of the stilts TAP validator accept any
integer type for these columns.

> 2. pol_states — Mandatory or optional?
> In Appendix B, Table 5 (Data Model Summary), the pol_states field
> is marked MAN = NO, indicating that it is optional. However,
> Section B.6.5.1 (List of Polarization States) describes pol_states
> as a mandatory field, with NULL permitted when polarization is not
> applicable. Could you please clarify whether pol_states is
> mandatory or whether its optional?

DaCHS includes pol_states, and it would be fairly non-trivial for you
to remove it.  May I ask why this bothers you (except that the spec
needs to be fixed, of course)?

Other than that I'd say the inconsistency is a case for a bug
against obscore <https://github.com/ivoa-std/ObsCore/issues>-

Thanks,

         Markus