On Mar 19, 2014, at 9:50 AM, Bill Burke <bburke_at_redhat.com> wrote:
>
>
> On 3/19/2014 8:31 AM, Santiago Pericas-Geertsen wrote:
>> Hi Sergey,
>>
>>> The fact the algorithm was written the way it was does not imply 'it works as designed' in this case. It is a bug.
>>
>> I don't understand your point here. The JAX-RS 1.0 EG agreed on a particular type of algorithm that they thought struck a nice balance between coverage and complexity (including no backtracking). You may or may not agree with the original design, but the algorithm is sound and the fact that it doesn't cover some cases does not make it "bug", just a different design.
>>
>
> The problem is that the spec is defining implementation detail rather than an API.
How could possibly have interoperability if you just defined a matching API? I wasn't part of the original EG, but I'm pretty sure the need to specify a matching algorithm was discussed. The spec clearly states, that you don't need to implement the algorithm the way it is described as long as your implementation is compatible.
> With the TCK enforcing this implementation detail you've made it impossible for us implementers to add any value. The current algorithm is both inefficient and incomplete. And because of the TCK/spec we can't improve it. This is just...for lack of a better word...crap and why both users and implementers hate the JCP.
I don't see why you cannot provide extensions to the algorithm (or anything else for that matter) in a non-standard way, as long as the default settings are compatible with the spec. BTW, standards work _is_ about compromising for the greater goal of interoperability.
>>
>> As I said above, the difficulty here is where to draw the line between what it is and what it isn't covered by the algorithm. I suggest that you take the existing algorithm as it in the spec, and propose modifications to it in such a way that it remains sound (backward compatible) with the original. If that could be done, without significantly increasing complexity, I do not see why we couldn't improve on the original design.
>>
>
> I'd rather just the TCK stop testing these edge cases.
I actually agree on this point. We should discuss it in the next round.
-- Santiago