users@jax-rs-spec.java.net

[jax-rs-spec users] [jsr339-experts] Re: Re: Matching Algorithm in Spec

From: Sergey Beryozkin <sberyozkin_at_talend.com>
Date: Fri, 9 Mar 2012 10:50:13 +0000

Hi Santiago

I've read the updated section (3.7.3.b).

I admit I'll have to read few more times, it reads like a complex
theorem proof at the moment for me :-).

I'm not entirely sure what matching media type issues/ambiguities the
updated text is supposed to tackle,

from you message below:

text/* ? application/xml


Here is the one fragment from your earlier message:

>>
>> On 2/13/12 8:46 AM, Santiago Pericas-Geertsen wrote:
>>> Hello Experts,
>>>
>>> When adding support for qs during matching (already in EDR2), I realized that step 3b in Section 3.7.2 is a bit vague (underspecified). After a few iterations, I came across a more precise (and more complex) description of this step. The original text handles the case of compatible types like:
>>>
>>> text/plain> text/*> */*
>>>
>>> quite well, but it's not precise when comparing incompatible types like:
>>>
>>> text/* ? application/xml

Is it about dealing with cases like this one ?

If yes, then do you really think it is important to add some precision
in matching two types like text/* & application/xml ?
As I said I'm still trying to grasp what I've read, so please tell me,
would the updated text make it feasible for
text/* & application/xml be matched ?

Thanks, Sergey




>>>
>>> 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?
>>>
>>> There are some other cases that are similar to these. In addition, there cases in which matching is clearly ambiguous for which the old algorithm was completely silent. The new one suggests that implementations issue a warning in these cases.
>>>
>>> Place take a look at the re-written step in [1] and provide feedback.
>>>
>>> -- Santiago
>>>
>>> [1] http://java.net/projects/jax-rs-spec/sources/git/content/spec/spec.pdf?rev=39d35e0fbf5949ba751a40b999900a4ed804852e
>>
>> --
>> Bill Burke
>> JBoss, a division of Red Hat
>> http://bill.burkecentral.com
>