VOTable 1.6 progress
Mark Taylor
m.b.taylor at bristol.ac.uk
Tue Mar 17 15:08:32 CET 2026
Pierre,
you are right that the templating syntax used by CDS in LINK elements
allows more flexibility than the key=value substitution provided
by DataLink resource descriptors.
Programming the Apps session in Strasbourg will be a matter for the
Apps chair, but I'd be happy to see a presentation of this topic
at the Interop.
For reference, I provide a reminder that we have considered templating
along these lines before, in 2019/2020; see the discussion starting
in Pierre's email here:
http://mail.ivoa.net/pipermail/dal/2019-November/008242.html
which was continued on github here:
https://github.com/ivoa-std/DataLink/issues/27
https://github.com/ivoa-std/DataLink/pull/28
and ended up with a draft proposal from Francois and Laurent about
using the existing standard templating syntax defined by RFC6570:
https://github.com/ivoa-std/DataLink/pull/54
The end point of that discussion was a decision to defer further
consideration until DataLink 1.2.
Mark
On Mon, 16 Mar 2026, Pierre Fernique wrote:
> Hi Mark,
> Thanks for giving me a little time to defend the interest of LINK in VOTable
> document.
>
> About the appendices, I have no objection to clean them up or even removed. As
> I mentioned, it is the LINK section where I would like to see improvements to
> make it useful. As I mentioned in my previous email, Datalink led us to
> believe that we could do the same thing as LINK+Appendix A.1. But
> unfortunately, that’s not true, or more exactly, partially wrong. Even with
> the Resource Descriptors added in an additional RESOURCE META section to avoid
> “doing it in two steps” (the example you cited), that doesn’t cover all the
> needs. Many URLs cannot be described by such a mechanism because they are not
> built on a baseUrl?key1=val1&key2=val2... schema. A simple example from this
> discussion: the URL https://github.com/ivoa-std/VOTable/pull/NN cannot be
> described by such a Resource Descriptor because it follows a “REST syntax” not
> covered by Resource Descriptor mechanism. Without getting ahead of the debate
> we may have at the Strasbourg Interop, DATALINK’s mechanisms were designed
> assuming control over the queried servers, and thus the ability to constrain
> URL syntax. As for LINKs, they have always been treated as links to any
> service, and therefore URLs must be used as such. The basic macro mechanism
> described in Appendix A.1 allows the entire URL syntax to be covered using a
> simple, compact, and consistent mechanism.
>
> If you're up for it, I'll prepare something on that topic for Interop
> Strasbourg.
>
> Bonne journée
> Pierre
>
> Le 12/03/2026 à 10:11, Mark Taylor a écrit :
> > 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/
> >
>
--
Mark Taylor Astronomical Programmer Physics, Bristol University, UK
m.b.taylor at bristol.ac.uk https://www.star.bristol.ac.uk/mbt/
More information about the apps
mailing list