On 08/04/13 17:06, Sergey Beryozkin wrote:
> Hi Santiago, All,
>
> I have some difficult time reading the section 3.7.2, specifically, the
> 3.7.2/3/b part, it starts from
>
> (1)
>
> "If after filtering the set M has more than one element, sort it in
> descending order as follows. Let
> a client media type be of the form n/m;q=v1 , a server media type be of
> the form n/m;qs=v2 and
> a combined media type of the form n/m;q=v1 ;qs=v2 ;d=v3 , where the
> distance factor d is defined
> below."
>
> and then it mentions, after specifying the terms:
>
> (2)
>
> "Given these definitions, we can now sort M in descending order based on
> ≥ as follows7 :
> • Let t be the request content type and CM a resource method’s @Consumes
> set of server
> media types, we use the media type max≥ {S(t, c) | (t, c) ∈ {t} × CM }
> as primary key.
> "
>
> Now, given that a 'qs' factor comes into consideration only when a
> client Accept values are checked against @Produces values, why have we
> defined a combined media type in (1) as having 'qs' and then presumably
> using that combined media types in (2), when referring to @Consumes ?
I think I understand why it is written this way, simply to have a
uniform algorithm text working for both @Consumes and @Produces, with
the Content-Type - @Consumes selection working with both 'q' and 'qs'
set to 1.0 by default.
My concern that some users may get an impression that for example
Content-Type: text/xml;q=0.8
can affect the selection of the underlying resource method which IMHO
does not make sense, because if it will affect then the client must be
knowing too much about the implementation details of the server.
If you share this concern then I can create an ice-box issue to get some
clarifications applied to the selection algo text in 3.7.2
Sergey
>
> Thanks, Sergey