Yalcinalp, Umit wrote:

> 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 :-)

Not disagreeing.

> --umit
>     ------------------------------------------------------------------------
>     *From:* David Hull []
>     *Sent:* Tuesday, Jan 17, 2006 8:21 AM
>     *To:* Yalcinalp, Umit
>     *Cc:*; 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 "_".
>>     -- 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
>>     "_". 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] _
>>     ----------------------
>>     Dr. Umit Yalcinalp
>>     Architect
>>     NetWeaver Industry Standards
>>     SAP Labs, LLC
>>     Email: Tel: (650) 320-3095
>>     SDN: _

Received on Tuesday, 17 January 2006 19:31:56 UTC