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
    * /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
> (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 16:21:30 UTC