<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body style="overflow-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;"><div>DeaI Apps,</div><div><br></div><div><blockquote type="cite"><div>On 2 Sep 2026, at 15:20, Mark Taylor via apps <apps@ivoa.net> wrote:</div><br class="Apple-interchange-newline"><div><div>Dear apps,<br><br>following up the discussion on templated LINKs:<br><br>On Wed, 11 Mar 2026, Pierre Fernique wrote:<br><br><blockquote type="cite">And during all these years, basic LINKs have always been used <br>continuously in VOTable according to the method described in the <br>appendix, mainly in CDS tools, Simbad outputs, VizieR ouputs, Aladin<br>tools, the CDS portal, and all partners wishing to see useful links<br>appear in a VOTable result.<br></blockquote><br>It is not really true that LINKs have been used "according to the<br>method described in the appendix"; Appendix A.1 of VOTable 1.5<br>discusses using the LINK templating "within a RESOURCE or a TABLE<br>element", to give "an implicitly defined new column of the table".<br>But the use of templating in CDS services that Pierre is discussing<br>is LINKs as children of FIELD elements to decorate the content<br>of such field values with hyperlinks, a usage which is not documented<br>in Appendix A.1. <br></div></div></blockquote><div><br></div><div>This is right, this is why PR#92 attempts to clarify the CDS pattern.</div><div>Note: A.1 is a little bit inconsistent since one RESOURCE can contain several tables, making the URL resolution with FIELD possibly ambiguous.</div><div><br></div><blockquote type="cite"><div><div><br>For example:<br><br> % curl -s 'https://simbad.cds.unistra.fr/cone?RA=83.8201&DEC=-5.3876&SR=0.01&VERB=1' | grep -A1 -B2 LINK<br> <FIELD ID="main_id" arraysize="*" datatype="char" name="main_id" ucd="meta.id;meta.main" utype="mango:MangoObject.identifier"><br> <DESCRIPTION>Main identifier for an object</DESCRIPTION><br> <LINK href="https://simbad.cds.unistra.fr/simbad/sim-id?Ident=${main_id}&NbIdent=1"/><br> </FIELD><br><br>(this one could alternatively be done using a service descriptor)<br></div></div></blockquote><div><br></div>AFAIK, SD does not work for path based URLs (e.g. <a href="https://simbad.cds.unistra.fr/simbad/get/sim-id/$%7Bmain_id%7D">https:/alt-simbad.dom.ain/get/sim-id/${main_id}</a>)</div><div><br><blockquote type="cite"><div><div><br>Appendix A.4 does talk about attaching LINKs to FIELDs in this way,<br>but uses a different syntax to the ${} templating of A.1 (as far<br>as I know this is not in use anywhere?)<br></div></div></blockquote><div><br></div>I never met this pattern.</div><div>I wouldn’t be worry to drop it, but to be sure not to break any standard compliance of existing implementations</div><div>the least we could do would be to deprecate the templating it proposes ($obs-no) and to replace it with (${obs-no}) .</div><div><br></div><div><blockquote type="cite"><div><div><br>This makes me think that anybody who is using the existing CDS<br>templating convention with FIELDs is doing so because they have<br>talked to CDS or have figured it out from looking at CDS-generated<br>tables, rather than because it's documented in Appendices of the<br>VOTable document.<br><br>So removal of Appendix A.1 doesn't put CDS's use of this<br>templating convention inside FIELDs in a worse position than<br>it is at VOTable 1.5 - it isn't documented properly now,<br>and it won't be if we delete the appendix.<br></div></div></blockquote><div><br></div>The idea was to make this position 'less worse' :-)</div><div><br><blockquote type="cite"><div><div>I feel that given this, deleting Appendix A.1 (as well as<br>all the other Appendices, which I think nobody objects to)<br>is the first thing to do.</div></div></blockquote><br><div><div>I agree, since Appendix A is somewhere in between a normative statement and a tip. </div><div>Therefore, we have to choose one option.</div></div><br><blockquote type="cite"><div><div>But since as Pierre points out the CDS templated FIELD/LINK usage is<br>in extensive and successful use, it should be documented somewhere.<br><br>There is then a separate question about whether the description of<br>this convention should be introduced as normative text in the VOTable<br>standard at VOTable 1.6 (Laurent's VOTable PR#92 has a go at this),<br>or whether it should be documented elsewhere, for instance in an<br>IVOA Note documenting CDS practice.<br><br>For a few reasons, I am inclined to prefer to see the documentation<br>in a Note:<br><br> - It overlaps with and provides a different way to do something<br> already specified by DataLink service descriptors, although<br> as Pierre has pointed out it covers some cases that SDs<br> currently cannot.<br><br> - A watertight definition of the syntax suitable for normative<br> text (e.g. as worked out in RFC 6570) could get complicated.<br> For instance, are there arrangements for escaping curly brackets<br> or dollar signs, how to treat null values, at what stage does<br> URI %-substitution take place?<br></div></div></blockquote><div><br></div>We have investigated RFC 6570 for DataLink 1.2 and the conclusion was that even its simplest level</div><div>was too complicated for our need ( I’m still not convinced of this). Therefore we got ride of it.</div><div>The situation is similar now and I believe we can live with the ${XXX} pattern without regard on the RFC.</div><div><br><blockquote type="cite"><div><div><br> - CDS currently uses this templating also in other contexts than<br> FIELD/LINK/@href, e.g. FIELD/LINK/@value as at<br> 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<br> I don't know whether there are others in use, e.g. TABLE/LINK/@href<br> and RESOURCE/LINK/@href as in the existing Appendix A.1?<br> Do we add all such usages to the VOTable document?<br> That could also get complicated.<br><br> - It's a usage that has at least till now been specific to CDS<br> services and clients. As such it hasn't before now had much<br> scrutiny by the wider VO community.<br><br>However, if the weight of opinion of interested parties is that it<br>should go in VOTable 1.6 itself, I'd agree to that.<br></div></div></blockquote><div><br></div><div>My inclination is to specify URL templating in the normative part, because it is a real feature that must be made available </div><div>to implementers (both clients and validators). </div><div>I recently discussed this issue with one Astropy contributor (Manon), who complained about the lack of clarity in the </div><div>LINK specification in general, and in particular with regard to URL templating. </div><div>I don't think a note would help to facilitate the job this.</div><blockquote type="cite"><div><div><br>Either way, it would be good to get this issue sorted out soon so<br>that we can move forward with VOTable 1.6 (my fault for not moving<br>quicker following the Strasbourg interop).<br><br>So: please follow up with your views, in particular on whether<br>the templating convention should be documented in VOTable 1.6,<br>or in a separate Note, or some other option.<br><br>Thanks,<br><br>Mark</div></div></blockquote><br><div><div>Laurent</div></div></div><br></body></html>