W3C home > Mailing lists > Public > public-ws-addressing@w3.org > March 2005

RE: MAPs and SOAP

From: Jonathan Marsh <jmarsh@microsoft.com>
Date: Fri, 18 Mar 2005 18:50:39 -0800
Message-ID: <7DA77BF2392448449D094BCEF67569A506E40442@RED-MSG-30.redmond.corp.microsoft.com>
To: "David Hull" <dmh@tibco.com>
Cc: <public-ws-addressing@w3.org>

> -----Original Message-----
> From: David Hull [mailto:dmh@tibco.com]
> Sent: Friday, March 18, 2005 2:26 PM
> To: Jonathan Marsh
> Cc: public-ws-addressing@w3.org
> Subject: Re: MAPs and SOAP
> 
> Could I ask everyone to please step away form the "why change the form
> of ReplyTo on the wire?" argument?  It's not relevant.  We can put
> ReplyTo on the wire however we want, whether or not MAPs are
> extensible.

Great, as I said before I'm happy to stop entertaining that part of the
proposal!

> The issue is whether I can easily add new kinds of endpoints to the
> MAPs and to the Addressing 1.0 properties.

IMHO no, you can't.  You can add new properties to your messaging
property bucket but since they aren't defined in the spec it would be
incorrect to call them WS-Addressing 1.0 properties. 

> , so that, for example, a
> processor wanting to know where ongoing messages could be sent only
> needs to know about WSA and not about an arbitrary number of
> extensions.

I still don't see why knowing where messages can be sent without
extension is useful if you still need to understand extensions to know
under what circumstances to send one of those messages.

> Yes, SOAP is extensible.  I can always define an entirely new module
> to hold my special-purpose endpoints.  If this is the approach, fine
> (actually, not fine IMHO, actually pretty lame, but so be it).  In
> that case, let's at least make this clear in our description of MAPs:
> They're hardwired toward async request/reply and you're completely on
> your own if you want to do more or different.

I'd be willing to clarify the use of the extensibility point for
advanced MEPs, if we can do it in a non-perjorative way.

Here's some proposed text.

Delete the "any" from the 3rd p of Section 3 as follows:

"Message addressing properties collectively augment a message with the
following abstract properties to support one way, request reply, and
other interaction patterns:"

Add a paragraph immediately preceding the 3rd p of Section 3 as follows:

"The set of message addressing properties defined in this specification
is sufficient for many simple variations of one-way and request-reply
MEPs.  More advanced MEPs may require additional message addressing
properties to augment the facilities provided here. "
Received on Saturday, 19 March 2005 02:51:19 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 2 June 2009 18:35:04 GMT