From m.b.taylor at bristol.ac.uk  Wed Sep  2 15:20:10 2026
From: m.b.taylor at bristol.ac.uk (Mark Taylor)
Date: Wed, 2 Sep 2026 14:20:10 +0100 (BST)
Subject: VOTable 1.6 progress
In-Reply-To: <463fa5e7-7225-4781-b436-02928e78baf4@astro.unistra.fr>
References: <92c46012-f72-1d94-c47-7ee6627bfe91@andromeda.star.bris.ac.uk>
 <463fa5e7-7225-4781-b436-02928e78baf4@astro.unistra.fr>
Message-ID: <2acf4741-eba9-26f7-30ab-c4bbc2e51cf@andromeda.star.bris.ac.uk>

Dear apps,

following up the discussion on templated LINKs:

On Wed, 11 Mar 2026, Pierre Fernique wrote:

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

It is not really true that LINKs have been used "according to the
method described in the appendix"; Appendix A.1 of VOTable 1.5
discusses using the LINK templating "within a RESOURCE or a TABLE
element", to give "an implicitly defined new column of the table".
But the use of templating in CDS services that Pierre is discussing
is LINKs as children of FIELD elements to decorate the content
of such field values with hyperlinks, a usage which is not documented
in Appendix A.1. 

For example:

   % curl -s 'https://simbad.cds.unistra.fr/cone?RA=83.8201&DEC=-5.3876&SR=0.01&VERB=1' | grep -A1 -B2 LINK
   <FIELD ID="main_id" arraysize="*" datatype="char" name="main_id" ucd="meta.id;meta.main" utype="mango:MangoObject.identifier">
   <DESCRIPTION>Main identifier for an object</DESCRIPTION>
   <LINK href="https://simbad.cds.unistra.fr/simbad/sim-id?Ident=${main_id}&amp;NbIdent=1"/>
   </FIELD>
    
(this one could alternatively be done using a service descriptor)

Appendix A.4 does talk about attaching LINKs to FIELDs in this way,
but uses a different syntax to the ${} templating of A.1 (as far
as I know this is not in use anywhere?)

This makes me think that anybody who is using the existing CDS
templating convention with FIELDs is doing so because they have
talked to CDS or have figured it out from looking at CDS-generated
tables, rather than because it's documented in Appendices of the
VOTable document.

So removal of Appendix A.1 doesn't put CDS's use of this
templating convention inside FIELDs in a worse position than
it is at VOTable 1.5 - it isn't documented properly now,
and it won't be if we delete the appendix.
I feel that given this, deleting Appendix A.1 (as well as
all the other Appendices, which I think nobody objects to)
is the first thing to do.

But since as Pierre points out the CDS templated FIELD/LINK usage is
in extensive and successful use, it should be documented somewhere.

There is then a separate question about whether the description of
this convention should be introduced as normative text in the VOTable
standard at VOTable 1.6 (Laurent's VOTable PR#92 has a go at this),
or whether it should be documented elsewhere, for instance in an
IVOA Note documenting CDS practice.

For a few reasons, I am inclined to prefer to see the documentation
in a Note:

  - It overlaps with and provides a different way to do something
    already specified by DataLink service descriptors, although
    as Pierre has pointed out it covers some cases that SDs
    currently cannot.

  - A watertight definition of the syntax suitable for normative
    text (e.g. as worked out in RFC 6570) could get complicated.
    For instance, are there arrangements for escaping curly brackets
    or dollar signs, how to treat null values, at what stage does
    URI %-substitution take place?

  - CDS currently uses this templating also in other contexts than
    FIELD/LINK/@href, e.g. FIELD/LINK/@value as at
    https://alasky.cds.unistra.fr/cgi/simbad-flat/simbad-cs.py?format=votable-cs&MAXREC=100&RA=130.054&DEC=19.621&SR=0.2
    I don't know whether there are others in use, e.g. TABLE/LINK/@href
    and RESOURCE/LINK/@href as in the existing Appendix A.1?
    Do we add all such usages to the VOTable document?
    That could also get complicated.

  - It's a usage that has at least till now been specific to CDS
    services and clients.  As such it hasn't before now had much
    scrutiny by the wider VO community.

However, if the weight of opinion of interested parties is that it
should go in VOTable 1.6 itself, I'd agree to that.

Either way, it would be good to get this issue sorted out soon so
that we can move forward with VOTable 1.6 (my fault for not moving
quicker following the Strasbourg interop).

So: please follow up with your views, in particular on whether
the templating convention should be documented in VOTable 1.6,
or in a separate Note, or some other option.

Thanks,

Mark

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