Hi Sergey,
> I admit I'll have to read few more times, it reads like a complex theorem proof at the moment for me :-).
Yes, I think it takes a couple of reads to get the idea.
>>>> 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 ?
It would basically cover the otherwise ambiguous cases below:
>>>> 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).
-- Santiago