Re: Demonstrating the obvious

This is very similar to the proposal [1] made by Marc -- which I think 
was option 4 in the strawpoll last week. Although the difference between 
your proposal and [1] is that, in [1] there is a URI attribute in the 
[endpoint] property that specifies the "role" of the endpoint.

-Anish
--

[1] 
http://lists.w3.org/Archives/Public/public-ws-addressing/2005Mar/0159.html


Nilo Mitra (TX/EUS) wrote:
> 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 Wednesday, 23 March 2005 20:27:20 UTC