Returning profiles for QSA queries

[kamhayfung]

In 7.1.3 (https://www.w3.org/TR/dx-prof-conneg/#listprofilestokenshttp), if the QSA approach is aimed at reducing the use of HTTP headers for humans, in what shape and form (e.g. media type) would a list of profiles be returned for a QSA based query instead of using HTTP headers? Should there be a convention?

[nicholascar]

(as discussed in the Profiles Negotiation sprint 2019-02-28)

The server will return a canonical list of profiles in the response's Link headers, however the server may also supply response content like this:

text/uri-list - fallback, unordered list of profile URIs
application/ld+json (any RDF format) - serialization of the Profiles Vocabulary
text/html - some human-readable version of the Profiles Vocabulary

[kamhayfung]

@nicholascar , the content suggestions look fine. Will they be added in the spec?

BTW, for completness can a server return both the Link header(s) and the human-readable content in the same HTTP response?

[rob-metalinkage]

I think it can...

NB

"The data sections of messages Error, Forward and redirection responses may be used to contain human-readable diagnostic information." [https://www.w3.org/Protocols/HTTP/HTRESP]

[nicholascar]

@kamhayfung: The proposal above is now in the document but there's a problem that needs to be fixed. For a HEAD request there's no body and for a GET request, the body content will necessarily be the default profile representation of the resource, so there's no room for the proposal body content above.

We'll try to resolve this ASAP.

[nicholascar]

This Issue has been side-stepped with the removal of the possibility for a QSA (or HTTP header) for HEAD or List Profiles to return an available profiles URI list in the body. HEAD has no body and GET will return the representation of the resource in the body