*IVOA DAL Running Meeting #17
*17 Oct 2023 20:00 UTC
Participants: François Bonnarel (FB), Pat Dowler (PD), Mark Taylor (MT), Tom Donaldson (TD), Renaud Saval (RS), Marco Molinaro (MM), James Dempsey (JD), Grégory Mantelet (GM)

*Datalink 1.1 RFC

	* Useful links:
		* RFC Page (https://wiki.ivoa.net/twiki/bin/view/IVOA/DataLink11RFC)
		* GitHub Pull Request #110 (https://github.com/ivoa-std/DataLink/pull/110)
		* (FB summary email) http://mail.ivoa.net/pipermail/dal/2023-October/008699.html

	* PD: Sympathizing with the current issue. There are several ways to solve this. The best would probably be to write an Informative (instead of Normative) Appendix.
	* MT: It does not look like a Datalink specific feature. Hence some resistance to include that in Datalink document.
	* TD: Something to think of in VOTable 1.6
	* MT: Preference for Implementation Note.
	* TD: Agreed to that.
	* FB: Agreed too. Have to start from scratch this note. Unfortunately not able to do that by the May Interop. However we could proceed with the Datalink recommendation in advance of the note being prepared.
	* TD: Using 'link' is not something I am used to deal with. This is the only concrete use case. Semantic of links fairly vague. Adding another column does not seem as the ideal solution either.
	* FB: Where to write the note?
	* PD: We can do that in github/ivoa
	* FB: Remove the section 3.1.1 from the PR.
	* GM: Is there any plan to integrate the content of this section in VOTable standard at some point (e.g. v1.6)?
	* TD: This capability does not require any change in VOTable to work.
	* MT, FB: Agreed.
	* FB: The content-type/MIME-type information, as Mark T. said, could be useful to clients for something else than Datalink. That could be of some interest in VOTable standard.
	* JD: Current clients likely do not support the link in field approach. Need to consider this as the note is developed.
	* TD: While working on the Implementation, recommend to make pull request to PyVO.
	* MT: Would consider adding support for link in field to TopCat
	* FB: PR will be updated very soon, but not the note (should wait after the interop).
	* FB: The reason of having 2 fields in Obscore was because the mime type of access_url can change from one row to another.