W3C home > Mailing lists > Public > public-ws-addressing@w3.org > January 2006

RE: cr17 (Ümit's OPTIONAL/REQUIRED issue) resolution

From: Yalcinalp, Umit <umit.yalcinalp@sap.com>
Date: Thu, 26 Jan 2006 16:33:47 -0800
Message-ID: <2BA6015847F82645A9BB31C7F9D64165FA0227@uspale20.pal.sap.corp>
To: "Marc Hadley" <Marc.Hadley@Sun.COM>, "Mark Nottingham" <mark.nottingham@bea.com>
Cc: "WS-Addressing" <public-ws-addressing@w3.org>

 

> -----Original Message-----
> From: public-ws-addressing-request@w3.org 
> [mailto:public-ws-addressing-request@w3.org] On Behalf Of Marc Hadley
> Sent: Thursday, Jan 26, 2006 7:20 AM
> To: Mark Nottingham
> Cc: WS-Addressing
> Subject: Re: cr17 (Ümit's OPTIONAL/REQUIRED issue) resolution
> 
> 
> My apologies for being absent during this discussion but I think this 
> resolution introduces a contradiction in the specification and 
> eliminates the opportunity for optimizing a common use case (omitting 
> wsa:ReplyTo for anonymous replies).
> 
> Section 5 of the WSDL binding document defines what abstract MAPs are 
> mandatory in each message of the WSDL 1.1 and WSDL 2.0 
> defined MEPs. In 
> each case where there is a reply message in the MEP, the [reply 
> endpoint] is marked as mandatory. Previously, when absence of 
> wsa:ReplyTo was a syntactic shortcut for inclusion of an anonymous 
> [reply endpoint], this requirement would be satisfied using 
> defaulting. 
> By removing the defaulting from the infoset serialization we now 
> *require* that wsa:ReplyTo always be present when a reply message is 
> expected.
> 
> I see two possible ways forward:
> 
> (i) Reinstate the defaulting in the infoset serialization
> (ii) Remove all instances of the mandatory [reply endpoint] in WSDL 
> binding section 5.
> 
> Of the two, I prefer (i) since a simple serialization 
> defaulting scheme 
> is simplest to implement.
> 
> Marc.
> 

Hi Marc, 

I brought up this issue  because the language in the CORE specification was simply contradicting itself as explained in my original issue posting. In my opinion, the core specification must be coherent regardless of the WSDL specification. It took a long time for the entire wg to be able to decipher what we were trying to say in the spec during the f2f due to the anomaly between MAP and the infoset serialization and defaulting intermingled. 

Therefore, I feel that it is not a WSDL issue and we should not do (i) and revert back to the previous definition. I would prefer fixing the WSDL spec. 

This is certainly not the first instance of problems with defaulting. Paco also has a CR issue with respect to defaulting to anonymous on request messages that we need to discuss. 


--umit



> 
> Mark Nottingham wrote:
> > 
> > as accepted by the group:
> > 
> > [ remove defaulting from infoset serialisation ]
> > 
> > 1. Select the appropriate EPR:
> > 
> >    a) If the reply is a normal message, select the EPR from 
> the related 
> > message's [reply endpoint] message addressing property. If 
> the MAP is 
> > not present, use an EPR with the [address] 
> > "http://www.w3.org/@@@@/@@/addressing/anonymous" and no 
> other properties.
> >    b) Otherwise, if the reply is a fault message and the related 
> > message's [fault endpoint] message addressing property is 
> not empty, 
> > select the EPR from that property. If the [fault endpoint] 
> property is 
> > not present, select the EPR that would have been selected 
> in step (a).
> >    c) In either of the above cases (a) or (b), if the 
> related message 
> > lacks a [message id] property, the processor MUST fault.
> >  2. Send the message according to [section 3.3 Sending a 
> Message to an 
> > EPR], but also including:
> >     a) [relationship]: this property MUST include a pair of IRIs as 
> > follows; the relationship type is the predefined reply URI 
> > "http://www.w3.org/@@@@/@@/addressing/reply" and the 
> related message's 
> > identifier is the [message id] property value from the 
> message being 
> > replied to; other relationships MAY be expressed in this property.
> > 
> > 
> > -- 
> > Mark Nottingham   Principal Technologist
> > Office of the CTO   BEA Systems
> > 
> > 
> 
> 
> 
Received on Friday, 27 January 2006 00:30:51 GMT

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