VOTable 1.6 progress

Thu Mar 12 10:11:56 CET 2026

Pierre,

it's definitely not too late!  Comments on this and other aspects
of VOTable going forward are very welcome.

I'd be happy to see a discussion about LINK as used by CDS
at the Interop or elsewhere.

Given your comments I do still think that something should be done
about Appendix A.  All the appendix says about the status of the
items it describes is that they are not part of VOTable but they
are candidates for VOTable improvements.

Although I am aware that there are some CDS-specific uses of LINK
elements, it's not at all clear what the relationship is between that
usage and text in the VOTable appendix; if Appendix A.1 (and the
related A.2?  others?) is supposed to be a description of behaviour
in use I didn't realise that.  As an author of VO tools I haven't
implemented that proposal, or individual cell encoding A.5,
or the XMLDATA serialisation A.8, or any other proposals in
Appendix A since I assumed they were just somebody's bright ideas
rather than a description/definition of actual implemented behaviour.

So if this usage of LINK is supposed to be behaviour that's
interoperable between different organisations, it should be described
in a place where its status is clearer; perhaps as you suggest within
the normative part of the VOTable standard (subject to WG and TCG
scrutiny) or maybe in an implementation Note.  Tidying up the
appendix and clarifying the status of items it contains is another
possibility, though not my favourite one.  In any case moving it
out of the Appendix doesn't mean that its use has to stop.
But, we can hold off decisions about deleting the Appendix until
this is resolved.

Concerning DataLink:

On Wed, 11 Mar 2026, Pierre Fernique wrote:

> 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.

This is untrue; you may be confusing the {links} endpoint with Resource
Descriptors, both defined in the DataLink document.  Resource Descriptors,
as defined in DataLink section 4, can do very much the same thing as
the CDS-favoured LINK behaviour, without the need for any additional
servers or other infrastructure.  Here is a drop-in Resource Descriptor
that does the same thing as the example in section A.1 of VOTable 1.5,
i.e. maps fields to URLs on a per-row basis to generate the templated
URL shown there:

  <RESOURCE type="meta" utype="adhoc:service">
    <GROUP name="inputParams">
      <PARAM ref="col3" name="Galaxy" datatype="char" arraysize="*" value=""/>
      <PARAM ref="col1" name="RA" datatype="float" value=""/>
      <PARAM ref="col2" name="DE" datatype="float" value=""/>
    </GROUP>
    <PARAM arraysize="*" datatype="char" name="accessURL" value="http://ivoa.net/lookup"/>
  </RESOURCE>

Such resource descriptors are deployed successfully in various
VO services including, I believe, VOLLT-based ones such as ARI-Gaia.
Topcat, in accordance with DataLink, recognises URLs built like
this but not CDS-style LINK templates; it sounds like Aladin
does the opposite.

Mark

On Wed, 11 Mar 2026, Pierre Fernique wrote:

> 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/
> > 
> > 
> > 
> > 
> 

--
Mark Taylor  Astronomical Programmer  Physics, Bristol University, UK
m.b.taylor at bristol.ac.uk          https://www.star.bristol.ac.uk/mbt/