<div dir="ltr"><div class="gmail_default" style="font-size:small">I am sure the intent was always to move with later versions of ObsCore, so I think it is just that at the time we put the ref to the only existing version. The language you quoted is certainly my attempt to just refer and not repeat the ObsCore spec. How should we be making references so they are forwards compatible e.g [ObsCore-1.0, ObsCore-2.0)? If we could have done that, is this an erratum to fix it?</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">Practically, I can think of an way to support both versions (ObsCore is a view already) by having an ObsCore10 view with associated metadata in tap_schema and then having SIA2 query that view instead of ivoa.ObsCore, but it's ugh and I think users would want/expect SIA and TAP queries of ivoa.ObsCore to be consistent... so I'd rather allow it than do this.<br></div><div><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><div>--<br></div><div>Patrick Dowler<br></div>Canadian Astronomy Data Centre<br></div>Victoria, BC, Canada<br></div></div></div></div></div><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, 4 May 2022 at 07:44, Markus Demleitner <<a href="mailto:msdemlei@ari.uni-heidelberg.de">msdemlei@ari.uni-heidelberg.de</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Dear DAL WG,<br>
<br>
I'm sure you've all been waiting for my next nitpicking of UCD use in<br>
DAL. Wait no longer. Except: this time, the cut is a bit deeper.<br>
<br>
SIAP 2 in section 3.1 ("Successful Query") says:<br>
<br>
The response from a successful call to the {query} resource is a<br>
table consistent with ObsTAP responses as described in [7].<br>
The ObsCore data model specifies all the (VOTable) field names,<br>
utypes, UCDs, and units to use in the response, as well as which<br>
fields must have values and which are allowed to be empty (null).<br>
The {query} response must contain the required ObsCore fields and<br>
may contain additional fields (from [7] or custom fields from the<br>
service provider). Examples <br>
<br>
[7] is a reference to Obscore 1.0, version-sharp.<br>
<br>
Which is where the trouble starts. Because, between Obscore 1.0 and<br>
Obscore 1.1, the UCD of the s_region column was changed from<br>
phys.area;obs to pos.outline;obs.field.<br>
<br>
Ever since I've moved by Obscore schema to 1.1, my SIAP 2 response<br>
has thus be invalid (brown bag for having ignored that for so long;<br>
cheers to Renaud for making it straightforward to have a simple<br>
command for "how do my services do"?).<br>
<br>
I *could* rather easily repair that by fiddling in the old UCD if<br>
DaCHS realises it is talking SIAPv2, but: Is this what we want?<br>
Shouldn't SIAPv2 just say "any response compliant to Obscore version<br>
1 is fine"? And if not, why? Would we then issue a new version of<br>
SIAPv2 whenever there's a new version of Obscore?<br>
<br>
-- Markus<br>
</blockquote></div>