W3C home > Mailing lists > Public > xml-dist-app@w3.org > February 2002

Re: Issue 154: Role invariance - proposed resolution

From: <noah_mendelsohn@us.ibm.com>
Date: Wed, 27 Feb 2002 13:14:53 -0500
To: Marc Hadley <marc.hadley@sun.com>
Cc: xml-dist-app@w3.org
Message-ID: <OFF4427EF8.58975BDF-ON85256B6D.004B769B@lotus.com>
Mark Hadley writes:

>> I therefore think that nodes are allowed to change the roles they play 
during message processing and we adequately describe the rules for doing 
so.

I think we need to be very careful here.   I think the formulation we have 
in the spec is indeed OK [1], but your informal summary is only right if 
viewed very carefully and an almost legalistic prism.    It is indeed true 
that you can change your roles during message processing, but not during 
header or body processing.  The text on optimistic methods is really a way 
of saying that we don't unduly constrain implementations, but the 
processing logic is strictly ordered.  Roles are determined in step 1 (and 
indeed you can inspect the message while doing this, but you MUST NOT 
proceed to processing headers and bodies in this step.)  Header and body 
processing is later in step 4, by which time the roles are fixed. 

[1] 

------------------------------------------------------------------
Noah Mendelsohn                              Voice: 1-617-693-4036
IBM Corporation                                Fax: 1-617-693-8676
One Rogers Street
Cambridge, MA 02142
------------------------------------------------------------------







Marc Hadley <marc.hadley@sun.com>
Sent by: xml-dist-app-request@w3.org
02/22/2002 08:27 AM

 
        To:     xml-dist-app@w3.org
        cc:     (bcc: Noah Mendelsohn/Cambridge/IBM)
        Subject:        Issue 154: Role invariance - proposed resolution


On wednesdays telcon I was assigned the action to draft resolution text 
for issue 154 [1] ahead of the F2F:

<quote>
Section 2.2 SOAP Actors and SOAP Node
   The roles assumed MUST be invariant during the processing of an
   individual SOAP message; because this specification deals only
   with the processing of individual SOAP messages, no statement is
   made regarding the possibility that a given piece of software
   might or might not act in varying roles when processing more than
   one SOAP message.
"invariant" - so if during the processing of a message a SOAP node
determines that it should also assume additional "roles", this would
be illegal?  I think this should be allowed.
</quote>

Proposed resoltion:

Since this issue was raised the text of the processing model has changed.

Section 2.6 now states:

"This section sets out the rules by which SOAP messages are processed. 
Unless otherwise stated, processing must be semantically equivalent to 
performing the following steps separately, and in the order given. Note 
however that nothing in this specification should be taken to prevent 
the use of optimistic concurrency, roll back, or other techniques that 
might provide increased flexibility in processing order as long as all 
SOAP messages, SOAP faults and application-level side effects are 
equivalent to those that would be obtained by direct implementation of 
the following rules in the order shown below.

1. Determine the set of roles in which the node is to act. The contents 
of the SOAP envelope, including header blocks and the body, MAY be 
inspected in making such determination."

According to rule 1 above we explicitly allow a node to inspect the 
message contents when deciding on the set of roles it is to play. We 
also allow a node to change the set of roles it plays after starting to 
process blocks provided that the outcome of this is "semantically 
equivalent to performing the following steps separately, and in the 
order given".

I therefore think that nodes are allowed to change the roles they play 
during message processing and we adequately describe the rules for doing 
so.

Regards,
Marc.

[1] http://www.w3.org/2000/xp/Group/xmlp-issues.html#x154

-- 
Marc Hadley <marc.hadley@sun.com>
XML Technology Centre, Sun Microsystems.
Received on Wednesday, 27 February 2002 14:40:02 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 7 December 2009 10:59:06 GMT