Appendix A.1 removed, LINK section revamped

[lmichel]

This PR is inspired by the proposal made by Pierre Fernique's about LINK at last interop (06/26).

• Appendix A.1 has been removed as suggest in Review Appendix A, "Possible VOTable extensions" #53.
• The use of templated LINK@ref has been described in a more generic way (context free).
• The use of templated LINK@ref has been moved to the LINK section.
• The processing of templated URLs is now described a more generic way in that normative section.
• The LINK section has been revamped for clarify
• change section updated accordingly

[mbtaylor]

@lmichel thanks for this PR which moves LINK templating into the body of the text; that might be the way to go though I think it still needs a bit more discussion.

However I note it also introduces into the main text two new values for the content-role attribute, "query" and "hints".

content-type="query" refers to the "VOTable Query Extension" subsection of Appendix A (A.2 in VOTable 1.5; A.1 in this PR). I struggle to understand the content of that appendix, as far as I know(?) it's not used anywhere, and it relies on some old/outdated standards (Astrores and ASU) - it's one of the appendices I was hoping to get rid of. So I'm not much in favour of including this option in the text.

content-role="hints": is this currently used anywhere? The suggested description: "indicates a pointer to information to be used by use by the application." doesn't say anything concrete about what you'd do with it.

[lmichel]

Appendix VOTable Query Extension

I agree that Appendix A1 in this PR (VOTable Query Extension) is likely deprecated since it refers to Astrores and ASU. I removed it as well as both hints and query LINK@content-role.

• The purpose of hints is (was) defined nowhere
• The query role is no longer used in the document

Allowed values for LINK@content-role

Another question about the normative part of the document is whether the values of the LINK@content-role property can be freely set or if they are limited to those defined in the document.
From my perspective, they should be freely assignable to allow for uses of LINK not specified in the current document.

Appendix A2 (FIELDs as Data Pointers) P37

This section gives another way to operate URL templating where the LINK href must be extended with the field value if FIELD@type="location" and FIELD.LINK@content-role="location" .
This pattern should logically be included in the normative section, but I'd prefer to get your approval before proposing something.

[tomdonaldson]

The specification of LINK allows all sorts of things without much guidance on semantics. That makes interoperability very difficult because I client can only guess at what the provider meant.

The successful uses of LINK so far involve conventions that are well understood by both provider and consumer. I was really hoping that we could make those use cases official here by being very explicit about what is provided and how a client should use that information. Without that, clients still would not know how to handle LINKs in general, and it's not clear to me that we would have improved the situation much.

[mbtaylor]

@lmichel wrote:

Appendix A2 (FIELDs as Data Pointers) P37

This section gives another way to operate URL templating where the LINK href must be extended with the field value if FIELD@type="location" and FIELD.LINK@content-role="location" . This pattern should logically be included in the normative section, but I'd prefer to get your approval before proposing something.

Please, no. The "FIELDs as Data Pointers" appendix contains yet another way alongside DataLink service descriptors and the CDS convention to do the same templating job, but with less flexibility than either. Unless somebody wants to argue, as for the CDS LINK convention, that this usage is so common it would be damaging to remove it then I would definitely like to delete this suggestion from the VOTable document.

[mbtaylor]

The specification of LINK allows all sorts of things without much guidance on semantics. That makes interoperability very difficult because I client can only guess at what the provider meant.

The successful uses of LINK so far involve conventions that are well understood by both provider and consumer. I was really hoping that we could make those use cases official here by being very explicit about what is provided and how a client should use that information. Without that, clients still would not know how to handle LINKs in general, and it's not clear to me that we would have improved the situation much.

Usage of LINK that's worked so far usually implicitly or explicitly uses content-role="doc" which is generally interpreted more or less like a hyperlink in a web page - it points to some external resource, maybe a web page, for dereferencing under human control. The only other defined content-role is currently "type", but as far as I can tell it's very rarely used.

DataLink service descriptors provide more complicated arrangements for annotating the semantics or format of referenced resources, and those can be used for non-trivial interoperability, but I don't see a compelling case for duplicating that sort of thing in LINK.

[msdemlei]

On Tue, Aug 25, 2026 at 05:27:02AM -0700, Mark Taylor wrote: convention, that this usage is so common it would be damaging to remove it then I would definitely like to delete this suggestion from the VOTable document.

+1 from me on this. Let's have one way to communicate recipes for URL creation in VOTable and one way only.