Re: Updated SOAP 1.2 Part 3 document

Replies to inline comments inline.

David Orchard wrote:

> Comments inline.
>
>  
>
> ------------------------------------------------------------------------
>
> *From:* David Hull [mailto:dmh@tibco.com]
> *Sent:* Thursday, June 08, 2006 12:58 PM
> *To:* David Orchard
> *Cc:* xml-dist-app@w3.org
> *Subject:* Re: Updated SOAP 1.2 Part 3 document
>
>  
>
> A few quick questions:
>
>     * The receiver MUST determine whether a message was successfully
>       received.  How can it do this, in general?  For example, the
>       sender sends a UDP message which falls on the floor.  The
>       receiver knows nothing.  How does it determine success or
>       failure, or even that anyone tried to send a message?
>
> DBO>> If a sender sends a UDP message on the floor and the receiver
> knows nothing, then it cannot determine that it successfully received
> a message.  I think the wording around this is for messages that the
> receiver has.
>
Perhaps we should tighten this up so that we know for sure.

>     * Is there one set of the given properties, shared by the sender
>       and receiver, or does each have its own copy?  I'm going to
>       guess that each has its own copy.
>
> DBO>> I think they each have their own copy, but it's the same as all
> the other properties in the other MEPS.
>
Ditto.

Some of the properties are shared, in that in the success case sender
and receiver will agree on their value.  In fact, that's pretty much the
definition of the success case.  We could try saying that directly,
instead of saying that they may disagree as to whether the operation
worked, with only the implication that "the operation worked" means
"they agree on property values."

This is exactly the sort of thing I've found loosey-goosey about the
SOAP specs from the start.

>     * The state property doesn't seem to be mentioned elsewhere in the
>       description.  Under which circumstances in the rest of the
>       description is which copy of the state set to what value, or
>       left undefined?
>
> DBO>> I agree it isn't mentioned elsewhere, and probably should.  How
> about something like "The SENDER should set the next value of State is
> Fail if itdetermines a FAULT has occurred then, otherwise the next
> value of State is Success" and the same for the RECIEVER.
>
Another way to look at it, without any status codes at all, is in terms
of events that may happen:

    * The sender sets up a set of properties, i.e., a message and
      "sends" it in a binding-specific way.  This happens exactly once
      per MEP.
    * A receiver receives a message consisting of those properties and
      runs the SOAP processing model on it.  This happens zero or more
      times with zero or more receivers (in the multicast case, the
      ImmediateDestination is a (dare I say it?) logical address, and in
      general the ImmediateDestination may not be the same as the
      receiver's idea of where it is).
    * The sender becomes aware of a fault.  This can happen zero, one
      and maybe more times.
    * A receiver becomes aware of a fault.  This can happen zero, one
      and maybe more times per receiver.


Normally, the receiver gets the exact same properties the sender sent
and no one gets a fault.  Ideally, if the receiver doesn't get the
properties or they're corrupted in transit, both parties get a fault,
but we recognize that there can be both false positives and false negatives.

I'm not sure we need a status code, since it will always be redundant
with "I got a fault" or "I sent/got a message and I didn't get a fault."
and we don't say what happens if, say, I get the same message, intact,
twice.  Rather than try to define status codes for all those cases, why
not just define what it means to receive a message and note, as above,
that it can happen zero or more times?  This lets bindings further
sharpen the semantics (e.g., I guarantee you'll get a message at most
once) and clients handle conditions as they see fit (e.g., I don't mind
getting the same message twice, so I don't need a "failure" status, or
conversely I do and I want a "failure" status).

The present text is not too far from this.  In particular, it does the
important work of defining the actual properties.  We just need to take
out the status code and translate the above into spec-ese.  The result
should be shorter than the equivalent text that includes the status code
and defines when and how it's set, since any full account of that will
have to cover the cases above.

>  
>
> David Orchard wrote:
>
> I've added some text based upon Noah's suggestions for describing
> sender and receiver responsibilities and changed to be SOAP 1.2 Part 3.
>
>  
>
> Let's talk on the list and the next telcon, whenever that occurs.
>
>  
>
> Cheers,
>
> Dave
>
>  
>