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.