RE: New CR Issue: OPTIONAL or REQUIRED?

David, 
 
I would prefer the specification to be very precise, and NOT confusing.
I made a fresh pass at the spec while we were discussing 
another issue and simply the sections contradict each other in 2
distinct ways (optionality vs. defaults + the meaning of "none"). 
 
Someone who is not in the WS-Addressing wg should be able to infer the
semantics without getting confused. If we the members of the wg find it
confusing, then it is a CR issue :-)
 
--umit
 


________________________________

	From: David Hull [mailto:dmh@tibco.com] 
	Sent: Tuesday, Jan 17, 2006 8:21 AM
	To: Yalcinalp, Umit
	Cc: public-ws-addressing-comments@w3.org; Francisco Curbera
	Subject: Re: New CR Issue: OPTIONAL or REQUIRED?
	
	
	I completely agree that defaults and optionality don't mix.
	
	However, as I understand it, the current definition is not
inconsistent (just a bit confusing):
	

	*	the response endpoint MAPs are indeed optional 
	*	in the context of XML infosets, a missing reply defaults
to anonymous while the fault endpoint has no default.  This is not
inconsistent; it only means that 3.2 says more than 3.1.  It's still
entirely possible to speak of an abstract message with no reply
endpoint.  You just won't see any represented in XML.  I'm not arguing
that this is clear or sensible, only that it's not inconsistent. 
	*	in the context of a request-reply operation, the
response endpoints have further restrictions. 

	So the [fault endpoint] really is optional.  In particular, you
can leave it off of a one-way message with no harm.  The [reply
endpoint] will default to anonymous whenever you use XML (um, pretty
much always, right?), but this is generally regarded as harmless.
	
	Yalcinalp, Umit wrote: 


		Several sections of the Core Specification [1] are in
contradiction wrt to the default values for reply endpoint and its
optionality. Currently the specification treats the reply endpoint as a
required property instead of an optional property and contradicts itself
in several sections as follows: 

		-- Section 3.1 lists reply endpoint/fault endpoint as
"optional" properties as their cardinality is defined as (0..1) 

		-- Section 3.2 lists the corresponding headers
wsa:ReplyTo/wsa:FaultTo as OPTIONAL elements. However,  the "default"
value for the reply endpoint property is designated to be anonymous URI.
This aspect makes the property required and is in conflict with its
definition in Section 3.1. Consequently, the message exchanges will
always assume a response, instead of using the URI
"http://www.w3.org/2005/08/addressing/none
<http://www.w3.org/2005/08/addressing/none> ". 

		-- Section 3.3.1 (Formulating a Reply Message) first
bullet second statement says "If none is present, the processor MUST
fault.". It is not clear what "none" refers to here. There are two
possibilities: 

		(a) There is no reply endpoint property (refers to "0"
as in Section 3.1). If this is the case, this is in contradiction with
the fact that there is a value (anonymous) as the "Note" in the
following paragraph suggests. This is again the reflection of the
contradiction between the sections in 3.1 and 3.2. Perhaphs the
intention of this paragraph is to say that there is always a reply
endpoint property when a reply is expected and it is an error not to
have a reply endpoint in this case. However, this intention itself
contradicts the fact that an EPR with an anonymous reply endpoint is
always assumed which will result in ALWAYS having a reply endpoint,
deeming it to be REQUIRED, not OPTIONAL. 

		(b) The value of the reply endpoint property is
"http://www.w3.org/2005/08/addressing/none
<http://www.w3.org/2005/08/addressing/none> ". This case is covered in
2, therefore probably (b) is not the intended semantics for "none". 

		Default values and optional values do not mix well. The
specification should clearly indicate whether the value is mandatory and
supplied by a default or optional. 

		Cheers, 
		--umit 


		[1] http://www.w3.org/TR/2005/CR-ws-addr-core-20050817/
<http://www.w3.org/TR/2005/CR-ws-addr-core-20050817/>  


		---------------------- 

		Dr. Umit Yalcinalp 
		Architect 
		NetWeaver Industry Standards 
		SAP Labs, LLC 
		Email: umit.yalcinalp@sap.com Tel: (650) 320-3095 
		SDN:
https://www.sdn.sap.com/irj/sdn/weblogs?blog=/pub/u/36238
<https://www.sdn.sap.com/irj/sdn/weblogs?blog=/pub/u/36238>