On 09/04/13 14:31, Santiago Pericas-Geertsen wrote:
>
> On Apr 9, 2013, at 6:05 AM, Sergey Beryozkin<sberyozkin_at_talend.com> wrote:
>
>> 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
>
> Implementations aren't required to implement the algorithm in the same manner, they just need to produce the same results. I'm fine with adding a sentence about quality factors in content types (a new JIRA), but I think it's pretty obvious that's not the intended use of q.
OK, this is definitely good enough for me. FYI I've just had a private
conversation where we had to talk about qs & q being defaulted to '1.0'
for this case - effectively ignoring whatever a user might've added by
mistake to either Content-Type ('q') or Consumes values ('qs'), hence I
started the conversation; guess I can open an ice-box issue - please
feel free to either act on it in the future or may be not, I agree it is
obvious, but some minor text tweaks may make it an easier read for some
users
Thanks, Sergey
>
> -- Santiago
>