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


So as long as we are talking about how to specify a char by char
comparison I have a few other questions about what we would need to
account for in an EPR comparison.

a) Do multiple wsa:ReferenceParameters attributes have to be in the same
order?  WS-Addressing seems to permit them to be re-ordered. That seems
to imply any comparison algorithm would have to take those permutations
into consideration. Would we need to specify that?
b) Does the comparison depend on any wsa:Metadata elements?
c) Does the comparison depend on any extension elements or attributes
not defined directly by WS-Addressing Rec?

Marc Goodner
Technical Diplomat
Microsoft Corporation
Tel: (425) 703-1903
Blog: http://spaces.msn.com/mrgoodner/ 


-----Original Message-----
From: Ashok Malhotra [mailto:ashok.malhotra@oracle.com] 
Sent: Wednesday, May 24, 2006 7:01 AM
To: Jonathan Marsh; Alastair Green
Cc: Anish Karmarkar; ws-rx@lists.oasis-open.org
Subject: RE: [ws-rx] i119: EPR comparisons overly restrictive

Jonathan:
sorry to be picky but you also need to specify the collation used for a
char-by-char comparison.  The XQuery F&O document recommends the Unicode
Codepoint Collation which seems right to me.

All the best, Ashok
 

> -----Original Message-----
> From: Jonathan Marsh [mailto:jmarsh@microsoft.com]
> Sent: Wednesday, May 24, 2006 6:44 AM
> To: Alastair Green
> Cc: Anish Karmarkar; ws-rx@lists.oasis-open.org
> Subject: RE: [ws-rx] i119: EPR comparisons overly restrictive
> 
> That sounds workable to me.  My preference, having been involved in 
> enough over-engineered standards work that was subsequently punished 
> by the industry, remains for the minimum necessary to declare victory.

> A new mechanism that optionally facilitates the use of an optional 
> optimization still seems like overkill to me.
> 
> And FWIW, I consider bit-for-bit (more precisely,
> char-for-char) as a respectable choice for a comparison algorithm.  It

> will generate a fair amount of false negatives but is dead simple to 
> implement.
> 
> > -----Original Message-----
> > From: Alastair Green [mailto:alastair.green@choreology.com]
> > Sent: Tuesday, May 23, 2006 10:00 PM
> > To: Jonathan Marsh
> > Cc: Anish Karmarkar; ws-rx@lists.oasis-open.org
> > Subject: Re: [ws-rx] i119: EPR comparisons overly restrictive
> > 
> > Jonathan,
> > 
> > Looking over the wall from my usual habitat in TX, I've
> been following
> all
> > of this for a while, because of related issues dealt with in TX. A
> quick
> > thought follows. Apologies in advance if it duplicates or
> misunderstands.
> > 
> > Perhaps you could walk right round this by defining an RX WS-A
> extension
> > element, which is of a clearly comparable type, and globally
> unambiguous,
> > e.g. absolute URI. "Interlocutor identity", "endpoint equivalence
> marker"
> > or some such.
> > 
> > If EPR A and EPR B (or EPR A') have such an element, both with value
> of
> > "foo" then you can send ack to EPR A on a message to EPR B. 
> You could
> re-
> > use this same id for the client identification issue for
> MakeConnection
> > too: reply EPR = anon/polling + interlocutor id.
> > 
> > I think you're right, that in this particular context where false 
> > negatives are just deoptimizations of the attempted optimization, 
> > "guessing the EPR equivalence" will work, and will, by evolution,
> chuck
> > out the bad guessers ( in reality, push most implementations to the 
> > conservative case of EPR comparison, e.g. bit-for-bit for [address]
> and
> > [ref params], or indeed to abandon the optimization).
> > 
> > In the client id case for GetMessage/MakeConnection I think you have
> the
> > problem that false negatives are dangerous. If you misidentify a
> request
> > to respond as coming from e.g. an unknown client then the two sides
> will
> > freeze up.
> > 
> > Overall, there seems to be a latent concept of "party to a
> conversation",
> > which might usefully be surfaced.
> > 
> > Alastair
> > 
> > Jonathan Marsh wrote:
> > 
> > 	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.
> > 
> > 
> > 
> > 
> > 
> > 
> 
> 
> 



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