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
Sergey
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
>>>
>>>
>>>
>>>
>>>
>>
>
>