RE: What does it mean for a MAP to be "mandatory"?

My understanding (worth checking) is that how the properties are
manifest in an envelope is described by a binding.  Our SOAP binding
says "the values of the SOAP 1.2 Addressing 1.0 Feature properties are
mapped to the message as SOAP header blocks..." [1] which presumably
means that any property with a value becomes a header block, and an
property without a value doesn't.  So if you are using a WSDL MEP with
the SOAP bindings we define, "mandatory" does mean a SOAP header would
appear.  For some other binding (including alternate bindings to SOAP),
you can write your own rules.

 

[1]
http://dev.w3.org/cvsweb/~checkout~/2004/ws/addressing/ws-addr-soap.html
#bindrefp

 

 

________________________________

From: public-ws-addressing-request@w3.org
[mailto:public-ws-addressing-request@w3.org] On Behalf Of David Hull
Sent: Friday, March 18, 2005 10:13 AM
To: public-ws-addressing@w3.org
Subject: What does it mean for a MAP to be "mandatory"?

 

I believe there has already been some discussion of this, and it relates
mainly to the WSDL binding in any case, but it also has to do with the
semantics of MAPs as (currently) defined in the core.  I've approached
much the same issue from a different angle previously in [1].

Section 4 of the WSDL binding begins

"This section describes which of the core message properties are
mandatory or optional for messages in the various MEPs defined by WSDL
1.1 and WSDL 2.0."

What does "mandatory" mean in this context?  Does it mean that
<wsa:ReplyTo> and <wsa:MessageID> headers MUST appear in a request
message, or would it mean that it MUST be possible for the receiver of
the request to determine values from them (whether they are present as
SOAP headers or not), or does it mean something else?

As far as I can tell, existing request/reply services would not be WSA
compliant in either case, as there generally isn't a message ID in an
HTTP request, nor any clear way to construct one, nor any particular
need to construct one.

One reason for asking this is to understand better the migration path
from current request/reply services to WSA aware "async request/reply"
services.

[1]
http://lists.w3.org/Archives/Public/public-ws-addressing/2005Mar/0171.ht
ml