RE: [ws-rx] i119: EPR comparisons overly restrictive

["Jonathan Marsh" <jmarsh@microsoft.com>]

I think you and I are pretty close on this.  We seem to agree that it is
desirable to allow a range of options from no optimization, to a simple
bit-for-bit comparison (though there may even be flavors of this),
through a canonicalized approach, through to what I'll call semantic
equivalence.   An implementation should be free to choose the level it
wishes to invest in, with the understanding that the more you invest,
the more optimization dividends you receive.

We don't seem to agree on the value of providing a non-normative
snapshot of a comparison algorithm in this spec.  IMO, such an algorithm
is likely to miss the sweet spot, provide an illusion of
interoperability when in fact it's just documentation of an
implementation detail, and consume a lot of TC time to work out details,
consume a lot of reader time to, and increase the burden of ongoing
maintenance of the spec.

I don't have a problem addressing the specific issue raised during
interop that reference parameters should be considered when determining
EPR equivalence.  I think the simplest way to address this issue is by
adding a simple warning to implementers along the lines of: "Note that
reference parameters should be considered when determining EPR
equivalence."  In this case the "very least" is perfectly sufficient.

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