UserPreferences

PaceAllowAnyMediaTypeForCategories


Abstract

Allow app:categories to point to resources that provide categories in additional media types to application/atomcat+xml.

Status

Proposal

Rationale

While it is reasonable to require category documents to be available as application/atomcat+xml, it is an unecessary limitation that content negotiation cannot be used to have the server reply with more expressive category documents such as Topic Maps, Thesauri, Ontologies etc. Given a particular client indicates it accepts other media types than application/atomcat+xml, why should APP disallow the server from replying with that media type if it is capable of doing so?

Proposal

Loosen the resriction that app:category elements must point to application/atomcat+xml documents and instead require that APP conformant servers MUST be capable of providing that media type but MAY reply with any other media type according to client capabilities.

Impacts

Chapter 7 of draft 11.

Existing applications would AFAICT not be impacted by this change.

Notes

If I am not missing something, APP cannot constrain HTTP in that way anyhow. While the cliet may make expectations about the returned media type based on link meta data, the returned Content-Type header is authoritative. Meaning: the client must check the header in any case.