On Apr 9, 2013, at 10:15 AM, Sergey Beryozkin <sberyozkin_at_talend.com> wrote:
> Me again,
>
> Content-Type: application/xml
>
> @Consumes({"application/*", "application/json"}) m1()
> @Consumes({"application/*"}) m2()
>
> I do not see anything in the 3.7.2 suggesting that m1() is to be preferred to m2(), simply on the basis it has more specific types than m2(). I recall Bill suggesting to take a number of more specific types into the consideration, but I guess it is up to the implementation which method to select here, m1 or m2, per the current spec text (assuming here no Accept-Produces step is to be done)
>
> Please correct me if the above is not the correct conclusion
I believe you're correct. Personally, I don't see a reason to prefer m2 over m1 (or vice-versa) in this case.
-- Santiago
> On 09/04/13 14:36, Sergey Beryozkin wrote:
>> One more thing.
>>
>> Can you please show where this sentence from 3.7.2,
>>
>> "For example, the following holds
>> text/html;q=1.0;qs=0.7;d=0 ≥ application/xml;q=1.0;qs=0.2;d=0 even
>> though text/html is in-comparable to application/xml according to..."
>>
>> starts making a difference,
>>
>> is it in a case like this:
>>
>> Accept: text/html, application/xml
>>
>> @Produces({"text/html;qs=0.7"}) m1()
>> @Produces({"application/xml;qs=0.3"}) m2()
>>
>> S(text/html, text/html), S(text/html, application/xml) =
>> text/html;q=1.0;qs=0.7;d=0
>> (for m1)
>>
>>
>> S(text/html, application/xml), S(application/xml, application/xml) =
>> application/xml;q=1.0;qs=0.2;d=0
>> (for m2)
>>
>> hence m1 wins...Guess yes, just typing away to get my spec knowledge to
>> the next level :-)
>>
>>
>> Thanks, Sergey
>>
>>
>> On 09/04/13 09:45, Sergey Beryozkin wrote:
>>> Hi
>>> On 08/04/13 18:15, Santiago Pericas-Geertsen wrote:
>>>>
>>>> On Apr 8, 2013, at 12:36 PM, Sergey Beryozkin<sberyozkin_at_talend.com>
>>>> wrote:
>>>>
>>>>> Hi Santiago
>>>>>
>>>>>>>>>> Here a few interesting cases:
>>>>>>>>>>
>>>>>>>>>> (I) Request (Accept: text/plain, application/xml)
>>>>>>>>>>
>>>>>>>>>> Resource {
>>>>>>>>>> @GET @Produces("text/*") m1() { ... }
>>>>>>>>>> @GET @Produces("application/xml") m2() { ... }
>>>>>>>>>> }
>>>>>>>>>>
>>>>>>>>>> Which method should be matched in this case?
>>>>>>>>>>
>>>>>>>>>> (II) Same as (I) but with q=0.8 in Accept:
>>>>>>>>>>
>>>>>>>>>> Request (Accept: text/plain, application/xml;q=0.8)
>>>>>>>>>>
>>>>>>>>>> What about in this case?
>>>>>>
>>>>>> It does not in any way complicate the algorithm implementation (it
>>>>>> obviously doesn't need to follow the formalization in the spec). It
>>>>>> does, however, resolve a number of ambiguous cases involving
>>>>>> _incompatible_ types that do not follow the simple m/n> m/*> */*
>>>>>> rule (for a fixed m and n).
>>>>>
>>>>> Is there any chance that you can give me a favor and 'apply' a spec
>>>>> text in this thread to cases (I), (II) and one more case involving
>>>>> incompatible types (please choose at your discretion) ?
>>>>
>>>> Sure.
>>>>
>>>> (I) - Step 3a has M = { m1, m2 }
>>>> - There's no t or C_M in this case (it's a GET!)
>>>> - A = { text/plain, application/xml }
>>>> We are looking for the max according to>= as follows:
>>>>
>>>> max>= {
>>>> S(text/plain, text/*), S(application/xml, text/*), // for m1
>>>> S(text/plain, application/xml), S(application/xml, application/xml) //
>>>> for m2
>>>> } =
>>>> max>= {
>>>> text/plain;q=1;qs=1;d=1, \bottom, // for m1
>>>> \bottom, application/xml;q=1;qs=1;d=0 // for m2
>>>> } =
>>>> application/xml;q=1;qs=1;d=0 // wins because of its value of d
>>>>
>>>> (II) Same as (i) except that in this case 'text/plain;q=1;qs=1;d=1'
>>>> wins because its q is> than 0.8.
>>>>
>>>> Hope this helps.
>>>>
>>> It does.
>>> IMHO, it is useful for the implementers to double check that the
>>> formalized approach produces the same result as the one deemed to be
>>> equivalent in the actual implementation; I was able to do that easily
>>> enough when working on a "setting the correct response type" task, but
>>> thought that I'd rather get some clarifications on 3.7.2 first.
>>>
>>> Thanks, Sergey
>>>
>>>> -- Santiago
>>>>
>>>>
>>>>
>>>>
>>>>
>>>
>>
>>
>