[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [ws-rx] i119: EPR comparisons overly restrictive
> -----Original Message----- > From: Anish Karmarkar [mailto:Anish.Karmarkar@oracle.com] > Sent: Monday, May 22, 2006 7:25 PM > To: Jonathan Marsh > Cc: ws-rx@lists.oasis-open.org > 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. Well said. Just because there is "an" algorithm does not mean that it is "the" one and only algorithm. > 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. Well said. > > 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]