OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

ws-rx message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [ws-rx] i119: EPR comparisons overly restrictive


These are all very good point.
But from them I don't necessarily conclude that we should not define an 
EPR comparison algorithm.

1) WRT to false negatives: I don't think false negatives are themselves 
a problem -- they result in one not being able to utilize the 
optimization. I would hope that if we define a comparison algorithm, it 
would be stated in a way that would *not* prevent anyone from defining 
additional mechanisms to figure out equivalence.
For example, if 2 EPRs are bit for bit the same then they are the same. 
If they are not (in absence of an equivalence algorithm), then one 
cannot make any statement about the equivalence (they may be equivalent 
or not, one just doesn't know). There may be additional metadata that 
tells me that they are (or not). For example, I may know that 
http://www.w3.org and http://www.w3c.org are the same. One should be 
able to add additional criterion (than the one that we define in WSRX, 
if we do at all) to figure out equivalence.

2) WRT to 3a and 3b: if we define a comparison algorithm, an 
implementation is not (or should not be) forced to use them. It may 
choose to ignore it (and only use, say, bit-for-bit comparison) at the 
cost of extra messages and a saving on processing. OR if it is willing 
to put additional resources to prevent extra messages, it may use 
additional criterion on top of what we define.

One of the feedbacks that I got from the interop was that some 
implementations ignore refps when figuring out equivalence -- this is 
quite bad for interop. If we don't define an equivalence algorithm, at 
the very lease we should include a warning about EPR comparisons and 
pitfalls.

-Anish
--

Jonathan Marsh wrote:
> I don’t have any religious objection to defining EPR comparison 
> mechanisms in specific circumstances (as WS-Addressing allows), but in 
> this case I fail to see why defining such a mechanism is a good thing.  
> In fact it seems harmful.
> 
>  
> 
> 1) Piggybacking is an optimization, although an important one.  Failure 
> to correctly determine that two EPRs are equivalent for the purposes of 
> piggybacking eliminates the possibility to benefit from the 
> optimization.  The nature of the optimization is in reducing the number 
> of messages sent on the wire.
> 
>  
> 
> 2) EPR comparison is tricky:
> 
>   a) URI comparison is notoriously difficult, unless the URI is simply 
> an identifier (e.g. namespace URI) and not primarily intended to be 
> dereferenced, in which case simple string comparison suffices.  I don't 
> believe this will suffice for [address] property values.  The current 
> reference to 2396 is confusing and inadequate to describe how URIs are 
> to be compared.  See http://www.ietf.org/rfc/rfc3987.txt section 5 for a 
> more thoughtful (and applicable) explanation of why there isn't a single 
> right mechanism.
> 
>   b) Comparing canonicalized representations of reference parameters is 
> also difficult.  There might be a broad set of allowable manipulations 
> to reference parameters that result in false positives, e.g. annotating 
> a ref param with an extension attribute (even WS-A does that).
> 
>  
> 
> 3) Despite the choices made above, both components of the proposed EPR 
> comparison can result in false negatives.  Trading off complexity of the 
> comparison algorithm versus the amount of optimization is a choice that 
> should be left to implementations.
> 
>   a) Canonicalization and full IRI normalization are fairly expensive.  
> Some implementations may prefer a simpler mechanism, with 
> correspondingly higher false negative rates.
> 
>   b) Network messaging is fairly expensive.  An implementation wishing 
> to expend extra computational resources to minimize the network traffic 
> should be free to implement as comprehensive a comparison mechanism as 
> they like.
> 
>  
> 
> A standardized EPR comparison mechanism writes into the standard 
> optimization choices that should be left to implementers, and would 
> force some implementations to become needlessly (from their perspective) 
> complex, and others to dumb-down and miss opportunities for better 
> optimizations.  Some seem to fear incorrectly piggybacking messages not 
> destined to the message recipient, which is again an implementation 
> issue (a bug) which the market will easily sort out.
> 
>  


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]