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


 

> -----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]