Re: high-level explanation of profile-based content negotiation

Hi Rob,

> 1) With polymorphism of profiles (profiles may be deeply hierarchical, and multiple profiles may be supported) the client may not be able to enumerate all profiles it supports - will there be support for wildcards and superclasses, or other ideas for handling this?

Could you clarify "deeply hierarchical"? How many layers would be talking about (roughly)?

The multiple profiles part will definitely be covered.
We haven't discussed wildcards yet;
superclasses should be okay if the server knows about the relationship.

> 2) There are many forms of content - for example map projection for spatial data, and certainly the level of detail in geometric properties, which will have the same role and data-type. Is the content negotiation going to be extensible across aspects

Yes; regarding "same datatype", this seems exactly the purpose of profiles over media types.

> and are those aspects defined by an authority register?

That is one option; there are multiple (which can be combined).

> (and by extension will existing dimensions of conneg - mime type and language be also supported in equilvalent form by a more general mechanism)

Yes, profile-based negotiation adds another dimension (on top of Content-Type);
the other ones remain supported.

> 3) is there a means to discover supported profiles (e.g. http HEAD accepting  *)

There will be.

> 4)  Can URL parameters be allowed to override the header (agent) negotiation - as per language negotiation practices?

Interpreting this question as: can negotiated representations also have their own URL?
Yes, they can.

Best,

Ruben

Received on Monday, 19 June 2017 19:23:02 UTC