VOTable 1.6 progress

[Laurent Michel]

DeaI Apps,

> On 2 Sep 2026, at 15:20, Mark Taylor via apps <apps at ivoa.net> wrote:
> 
> 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.

This is right, this is why PR#92 attempts to clarify the CDS pattern.
Note:  A.1 is a little bit  inconsistent  since one RESOURCE can contain several tables, making the URL resolution with FIELD possibly ambiguous.

> 
> 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}&NbIdent=1"/>
>   </FIELD>
> 
> (this one could alternatively be done using a service descriptor)

AFAIK, SD does not work for path based URLs (e.g. https:/alt-simbad.dom.ain/get/sim-id/${main_id} <https://simbad.cds.unistra.fr/simbad/get/sim-id/$%7Bmain_id%7D>)

> 
> 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?)

I never met this pattern.
I wouldn’t be worry to drop it, but to be sure not to break any standard compliance of existing implementations
the least we could do would be to deprecate the templating it proposes ($obs-no) and to replace it with  (${obs-no}) .

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

The idea was to make  this position 'less worse' :-)

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

I agree, since Appendix A is somewhere in  between a normative statement and a tip. 
Therefore, we have to choose one option.

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

We have investigated  RFC 6570 for DataLink 1.2 and the conclusion was that even its simplest level
was too complicated for our need ( I’m still not convinced of this). Therefore we got ride of it.
The situation is similar now and I believe we can live with the ${XXX} pattern without regard on the RFC.

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

My inclination is to specify URL templating in the normative part, because it is a real feature that must be made available 
to implementers (both clients and validators). 
I recently discussed this issue with one Astropy contributor (Manon), who complained about the lack of clarity in the 
LINK specification in general, and in particular with regard to URL templating. 
I don't think a note would help to facilitate the job this.
> 
> 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

Laurent

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.ivoa.net/pipermail/apps/attachments/20260903/b1ee8eea/attachment.htm>