Open jontxu opened 7 months ago
To clarify, the existing behaviour is not non-compliant, since TAPRegExt only suggests rather than requires the ivo-id attributes as above, but it would be nicer if the VOLLT implementation did include them.
Thanks for the clarification, I edited the title and comment accordingly.
Indeed, this attribute is optional. When I developed this part of VOLLT, I guess I did not know which IVO-ID to write in this attribute and whether it would be useful or not. It seems to be now useful and thanks to your example, I have a clear idea on the value to write for this attribute. Thanks to both of you for this feedback. It is indeed a trivial change to implement. I'll include that in the next stable release of VOLLT/TAP-Lib.
Hi, I was notified by @mbtaylor that the
capabilities
endpoint from our TAP service does not follow the TAPRegExt recommendation as it lacks theivo-id
attribute for the relevant output formats (outputFormat
in the XML). This ID is used by some clients to interpret (for the time being) VOTable types, as shown on the recommendation: https://www.ivoa.net/documents/TAPRegExt/20120827/REC-TAPRegExt-1.0.html#outformsCurrent output:
Expected (TapRegExt-supporting) output:
Looking into the code, seems like its implementation is somewhat trivial, by adding support for a
ivoId
field intap.formatter.OutputFormat
(and the classes which implement it) and adding the attribute when getting the output formats when writing the capabilities intap.resource.TAP
.