- From: Nilo Mitra (TX/EUS) <nilo.mitra@ericsson.com>
- Date: Tue, 22 Mar 2005 14:12:20 -0600
- To: David Hull <dmh@tibco.com>, public-ws-addressing@w3.org
I hope I'm not being naive, and this comment isn't intended to affect the LC decision in any way, but... > * Dave Orchard's request/reply/alternate reply example. An alternate reply message would include an "alternate reply" relation in > [relationship], but the alternate reply endpoint itself would be defined outside the MAPs. > * The initial/normal processing/urgent processing/fault case I gave. From a narrow viewpoint of counting inbound and outbound endpoints, this > is isomorphic to the previous case, but the endpoints here would all be defined outside the MAPs. could these cases be handled by NOT defining new "types" of reply endpoints (outside the core) but allowing a MAP to have multiple [reply endpoint]s and leaving it to some other (higher layer) spec to define how one or the other or all of these alternative endpoints would be used, including the value of the [relationship] property when using any of these endpoints. The metadata for these [reply endpoint]s could describe the circumstances when each alternative is used, such as fallback, normal reply, urgent reply, whatever... etc. This would IMO mean small changes to the Core (changes highlighted ***thus***): [reply endpoint] : endpoint reference ***(0..N) where N>=1*** An endpoint reference for the intended receiver for replies to this message. If a reply is expected, a message MUST contain ****at least one*** [reply endpoint]. The sender MUST use the contents of the ***chosen*** [reply endpoint] to formulate the reply message as defined in 3.2 Formulating a Reply Message. If this property is present, the [message id] property is REQUIRED. ***The semantics and usage of such multiple end points is outside the scope of this specification.*** ..or words to that effect. Thanks, Nilo
Received on Tuesday, 22 March 2005 20:13:08 UTC