VOTable 1.6 progress

[Pierre Fernique]

Dear Apps members,

Perhaps I was not responsive enough during the preparation of this new 
revision of the VOTable document. I apologize for this, and hope that I 
am not too late. The proposed deletion of Appendix A raises a 
fundamental question about the implementation of links associated with a 
VOTable. I would appreciate it if we could discuss this at the next 
Interop meeting before deciding on this issue, which has been raised on 
occasion but has never been debated in plenary session (to my 
knowledge). For now, I would like to reiterate the point that I believe 
is important to bear in mind before proceeding with this deletion.

Historically, the authors of VOTable had planned to implement LINK 
(basic HTTP URL) associated with a column (FIELD), and in the appendix, 
they suggested a method for extending the use of these LINKs to each 
column value. Here is a reminder of the idea: a LINK HREF=http://... in 
a FIELD section of the header, which could refer to a certain value in 
each row via a ${refID} macro to allow the client to construct each 
specific URL (e.g., http://simbad/query?object=${ident} where “ident” 
refers to the ID of a column). Nothing more than a simple macro mechanism.

In fact, links associated with a VOTable value are a valuable and 
indispensable feature for users of Aladin, the CDS portal, and any other 
client who wishes to offer the users a means of accessing associated 
information via a standard HTTP link. However, since at the time this 
method was only implemented in CDS tools, and no other client saw the 
need for it, this method was not included in the VOTable 1.0 document 
and subsequent versions. LINK was indeed included, but the use of ${..} 
macros was moved to an appendix pending a more widespread need and 
further discussion. The document retained the possibility of associating 
a URL with a column as a whole, which is of little interest and has 
never been used. Later, the same LINK was reused to describe semantics 
(SKOS concept) associated with a column. To my knowledge, this idea has 
never been implemented and has unfortunately made it even more difficult 
to understand the use of LINK. This is indeed a situation that must and 
can be improved.

Meanwhile, the need for links associated with a VOTable resurfaced in a 
less CDS-oriented way, giving rise to the DATALINK standard and all the 
associated developments. There has been a significant effort on the part 
of the IVOA community, and a concrete, very real implementation. 
Unfortunately, in practice, and contrary to what one might have hoped, 
this standard makes it quite difficult to replicate what basic LINKs 
already do. Specifically, via DATALINK, it is necessary to implement a 
server dedicated to the a posteriori generation of the additional 
VOTable providing the templating for the generation of one or more 
links. For a single link, this is complicated, cumbersome, and in 
practice almost never implemented for such a use. In short, DATALINK 
does not do the same job.

And during all these years, basic LINKs have always been used 
continuously in VOTable according to the method described in the 
appendix, mainly in CDS tools, Simbad outputs, VizieR ouputs, Aladin 
tools, the CDS portal, and all partners wishing to see useful links 
appear in a VOTable result.

Furthermore, VOLTT should integrate the implementation of these “basic” 
LINKs into its next version, taking into account ${refID} macros, and 
will offer all VOTable authors via TAP a simple way to indicate links on 
VOTable values. This is already what Simbad actually uses in its TAP 
outputs.

Since the benefits of having associated links to a VOTable are no longer 
in question, I think it might be time, not only to remove the appendix 
describing the macro method, but rather to finally integrate it into the 
normative section, by limiting this macro mechanism to what is strictly 
necessary, focusing on what DATALINK does not and will not do. In short, 
a simple alternative to describe basic link for an easy-to-use linking 
mechanism.

If you agree, I suggest presenting all of this again at the next Interop 
IVOA meeting so that we can finally make progress on this issue. I can 
also propose a new draft of the relevant LINK section.

Pierre

Le 10/03/2026 à 13:14, Mark Taylor via apps a écrit :
> Dear Apps,
>
> I have made a couple more pull requests for VOTable:
>
>     Delete Appendix A "Possible VOTable Extensions"
>        https://github.com/ivoa-std/VOTable/pull/83
>
>     Remove outdated comments from XSD file:
>        https://github.com/ivoa-std/VOTable/pull/84
>
> If you have comments/objections/suggestions related to those proposals,
> please record them there or, if you don't like github, on this list.
>
> I *think* that completes the changes to the VOTable document that
> I proposed in Gorlitz or have otherwise decided are a good idea,
> ready for VOTable 1.6.  So subject to discussions on the above pull
> requests or other comment, my current plan is to merge those in the
> next couple of weeks and then issue a VOTable 1.6 Working Draft well
> in advance of the Strasbourg Interop.
>
> Any other pull requests, issues or other input on the path to
> VOTable 1.6 are of course very welcome.
>
> Mark
>
> --
> Mark Taylor  Astronomical Programmer  Physics, Bristol University, UK
> m.b.taylor at bristol.ac.uk          https://www.star.bristol.ac.uk/mbt/
>
>
>
>