[jax-rs-spec users] [jsr339-experts] Re: Re: Some issues with section 3.7.2

From: Sergey Beryozkin <>
Date: Wed, 15 May 2013 10:22:47 +0100

Hi Santiago, All,

I'd like to briefly get back to this thread, see comments in the end of
the message

On 09/04/13 14:46, Sergey Beryozkin wrote:
> On 09/04/13 14:31, Santiago Pericas-Geertsen wrote:
>> On Apr 9, 2013, at 6:05 AM, Sergey Beryozkin<>
>> 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.

Right, so 'q' is obviously not for the use with Content-Type.

Can you please confirm 'qs' is not for the use with @Consumes values ?
I'm seeing a test asserting that adding 'qs' to @Consumes values affects
the selection of the methods.

I think 'q' & 'qs' can work in tandem in order to 1) get the right
response type and 2) possibly affect the selection of the method

Using 'qs' in @Consumes simply as a means to get a method selected is
feasible but I wonder if it was actually intended (referring here to the
spec text)


Content-Type: text/plain

@Consumes("text/*") m1()
@Consumes("text/plain;qs=0.8") m2()

m1 wins apparently. In fact m2() can never even be selected if we take
into the consideration that 'q' is not supposed to be used with

So, do we allow for the use of 'qs' on @Consumes. IMHO it has to be
defaulted to 1.0 no matter what custom values are, thoughts, comments ?

Thanks, Sergey