On 5/20/2013 9:52 AM, Santiago Pericas-Geertsen wrote:
>
> On May 20, 2013, at 9:40 AM, Bill Burke <bburke_at_redhat.com> wrote:
>
>>
>>
>> On 5/20/2013 9:23 AM, Santiago Pericas-Geertsen wrote:
>>>
>>> Yes, I thought the original example was the other way around, but I agree with this one. I think this was an unfortunate copy/paste error in the definition of M (from earlier in step 2). It should be,
>>>
>>> M = { subresource methods of all classes in C′ where R(T_method) = R_match (excluding sub-resource locators) }
>>>
>>> which should result in M = \empty and no jump to step 3.
>>>
>>> Make sense?
>>>
>>
>> There's still other holes (see my previous email). Additionally , what about this case?
>
> Aren't we going back to the discussion of more general matching algorithms? If that's the case, you should consider enabling/disabling this extension in your implementation. Otherwise, we can't guarantee any portability between implementations, which is what we are trying to do here.
>
Usually, I'd be 100% in agreement with your portability argument, but in
this case, we have a buggy algorithm that doesn't support many of these
edge use cases. This is what you get when you try to standardize an
implementation detail. The fact we would have to have a special switch
to get around a buggy spec matching algorithm is just bullshit.
Instead something more general should be in the matching section:
1. Both Resource methods and locators should be taken into account to
match requests
2. More explicit expressions take precedence over less explicit ones.
i.e. @Path("path1111") takes precedence over @Path("path{id}")
3. If there is are resource methods that matches the path, but not the
HTTP method, return 405
4. If there are resource methods that match the path and HTTP method,
but not the media type, return 415
5. If the request is an OPTIONS request and there is no match, do this
default behavior
6. If the request is HEAD and there is no match, but there is a GET
request, do this default behavior...
7. If there is an error when matching through a locator, do this...
Ambiguous use cases should not be tested by the TCK. What is actually
categorized as "ambiguous" should be resolved by TCK challenges.
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com