Clarify how to refer to alternates view methodology for profile neg

[nicholascar]

This issue was created in the Conneg by Profile document and is listed in it. Once consensus on addressing it is reached here in comments below, the results will be added to the document and the issue closed.

The Use Case Web browser navigation of profile information is recorded but no DXWG method is yet proposed. In prior art, the so-called alternates view method is listed. This method is not yet aligned with the IETF proposal.

[nicholascar]

I propose proceeding with an assumed future version of the alternates view method that is aligned with the IETF proposal in order to allow for demonstration answers for Requirements in the Profile Guidance and Conneg documents.

Suggested changes to the alternates view approach to align with the IETF proposal:

• "view" generally to be replaced with "profile"
  • alternates view -> profile listing view
  • Query String Argument _view -> _profile
• "format" generally to be replaced with "media type"
  • Query String Argument _format -> _mediatype
• include definitions in the approach to cater for all Accept-* headers
  • approach already includes Accept, Accept-Language but is missing Accept-Charset, Accept-Encoding, Accept-Datetime

[rob-metalinkage]

I think we need to first canvas options 0) no ability to have options or discover profile conformance of default option for resource 1) no ability to dereference a URI to a specific profile except via software support (header manipulation) 2) Descriptions of all content negotiation options embedded in every resource 3) Servers responsible for delivering list of options and clients able to invoke this special metod 4)Third party cataloguing of metadata about options, and a canonical means for clients to discovery and access this third party 5) provision of a specific resource describing options (directly by link from the resource, by querying the server) from the server or a designated link to a third party resource) - aka the alternates view 6) ?.

These are not mutually exclusive, but AFAICT other than 5 put a very high burden on clients outside of very specific machine-mediated smart client scenarios.

[larsgsvensson]

Suggested changes to the alternates view approach to align with the IETF proposal:

Let's don't change anything here before Ruben and I haven't got around to updating the I-D. We'll work on that during October/November.

[nicholascar]

Rob & I think we can define an abstract API to emulate HTTP methods for multiple other implementations (QSA, REST API etc.) and then the current _view, _format Alternates View system can map its terminology to that thus avoiding having torename anything. But the AV system will have to be feature complete with the HTTP methods in order to be a full implementation, so the part about supporting Accept-Encoding etc. is still relevant.

We'll roll support for the other HTTP conneg headers into https://github.com/rdflib/pyLDAPI starting now (we need to the tookit updated anyway) but this won't affect alignment with any changes you and Ruben might make to the I-D.

[nicholascar]

This Issue has been dealt with by defining the two QSA Functional Profiles in the 3PWD candidate, see https://w3c.github.io/dxwg/conneg-by-ap/#qsa-listprofiles, that implement list profiles.

[nicholascar]

Closing after listing in plenary 2019-09-03 + 3-day wait period.