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




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?


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.


Chapter 7 of draft 11.

Existing applications would AFAICT not be impacted by this change.


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.