RE: Issues against editor's draft

David,

 

I believe the latest ed copy deals with all these concerns as you would
like.  The State and FailureReason properties are removed, the
receiver's determination of success is more clearly specified including
when inboundmessage is set, and multi-cast is now supported.

 

Please advise us ASAP if you have any follow-on or different concerns.

 

Cheers,

(other)Dave

 

________________________________

From: xml-dist-app-request@w3.org [mailto:xml-dist-app-request@w3.org]
On Behalf Of David Hull
Sent: Wednesday, July 19, 2006 9:38 PM
To: xml-dist-app@w3.org
Subject: Issues against editor's draft

 

Summarizing previous discussion:

*	It appears that the sender and receiver have separate copies of
the properties, but this is not explicitly mentioned.
*	The State property is defined as containing either Success or
Fail "at a terminal state", but there is no mention of when which copy
of this property takes which value, or when "a terminal state occurs",
or in what way the property containing Fail may correspond to generation
of faults.
*	The FailureReason property "denotes a pattern-specific,
binding-independent reason for the failure of a message."  Given that a
binding-independent reason cannot be defined by a particular binding,
and no such reasons are mentioned in the MEP description itself, where
are such reasons to be defined?
*	It seems likely, though again this is not stated, that "more
binding-specific details of the failure" may bear some relation to
faults produced by the sender or receiver.  Is there any such relation?
*	Addressing the previous three points would most likely only
complicate matters, and in any case error handling is driven by the
generation and disposition of faults.  It seems best to drop the
properties altogether.
*	The receiver MUST determine whether a message was successfully
received.  It is not stated explicitly, but presumably this would be for
a given instance of the MEP.  In some realizations of the MEP, it will
not necessarily be possible for the receiver to know that the sender has
done anything at all.  In practice, either the receiver's set of
properties will be populated, or it won't.  This argues for defining
receipt of a message as population of the receiver's set of properties,
and stating that this can happen zero or more times in a given instance
of the MEP.
*	Unlike the request-response case, it is quite feasible and
useful to realize the one-way MEP directly in a multicast environment.
In such an environment, there may be zero or more receivers for any
given message -- that is, for a given ImmediateDestination -- and this
set may change from instance to instance of the MEP.  The statement that
"The scope of a one-way MEP is limited to the exchange of a message
between one sending and one receiving SOAP node." directly precludes
this useful behavior.  Nor can multicast be usefully treated as multiple
MEP instances without specifying how it is that the instances share the
OutboundMessage property and how the limitation to exactly one sender
and receiver squares with the case where there is one sender and no
receiver.  Spelling out such a scheme would add needless complexity.

Proposal:

A revised proposal [1] eliminates the redundant and under-specified
properties, explicitly states that the sender and receivers each have
their own copies of the remaining properties, states that a receiver's
properties may be populated zero or more times in an instance of the
MEP, and specifically allows for multicast.  This proposal also attempts
to state more explicitly what a valid binding is obligated to define.
Further discussion [2] has suggested further possible clarifications,
particularly regarding the use of the term "notification of receipt".
These should be discussed and possibly incorporated.

[1]
http://lists.w3.org/Archives/Public/xml-dist-app/2006Jun/att-0004/one-wa
y-mep-june-2006.html
[2] http://lists.w3.org/Archives/Public/xml-dist-app/2006Jul/0001.html
and following thread