VOTable 1.6 progress

Mon Mar 16 12:08:38 CET 2026

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