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

RE: Proposed rewrite of Part 1, section 2 (long)

From: <noah_mendelsohn@us.ibm.com>
Date: Wed, 6 Feb 2002 14:30:03 -0500
To: jcieslak@us.ibm.com
Cc: "Williams, Stuart" <skw@hplb.hpl.hp.com>, xml-dist-app@w3.org
Message-ID: <OF3E19DF8A.E522ED69-ON85256B58.0069968E@lotus.com>
To the editors:

Thank you for undertaking this.  I think you have done an excellent job, 
and overall it's a big step forward.  I too prefer the "radical" change 
that gets rid of the term "actor".  Here are a couple of comments on areas 
of the rewrite that do concern me a bit.

One significant change that I would suggest: you have struck out the text 
that the end of section 2.5 that reads;

"When multiple body elements are present, such elements MAY represent a 
single unit of work to be performed, MAY represent multiple separate 
processing steps, possibly but not necessarily in order, MAY represent 
data or metadata, MAY convey a mixture of work units and data, etc. The 
ultimate SOAP recipient MAY use the local name(s) and namespace name(s), 
on any or all body elements, to determine the processing to be performed. 
Indeed, the SOAP RPC convention (see [1]Using SOAP for RPC ) uses just 
such a method. Conversely, other information in the body and/or headers 
MAY be used to make such a determination.[2]"
I agree that the specification is coherent without this paragraph, but we 
discovered when we considered bodies and consulted with soapbuilders, that 
different readers of the specification inferred conflicting "obvious" 
interpretations for the use of <body>.  I think that this paragraph, or 
something like it goes a long way toward clarifying our intention.  I 
would keep it, or possibly reword it (I don't find it too bad as it 

Another less serious concern: 
In section 2.2 you removed the sentence that says "A SOAP node can 
establish itself as the ultimate SOAP receiver by acting in the 
(additional) role of the anonymous SOAP actor."  In section 2.3, you do 
say "A SOAP header block is said to be targeted to a SOAP node if the SOAP 
actor role (if present) on the header block matches (see [7]) a role 
played by the SOAP node, or in the case of a SOAP header block with no 
actor role attribute information item, if the SOAP node is acting in the 
role of the ultimate SOAP receiver." 
The reason this bothers me a bit is that we have muddied the notion that 
there is a set of roles in which a node acts, with that set triggering the 
processing of headers in a uniform manner.  I agree that the term 
"anonymous actor" could be improved, but the proposed revision makes the 
processing of untargeted headers at the endpoint look like magic.  Perhaps 
more disturbingly, it leaves somewhat vague the question of whether an 
intermediary could also choose to serve in the role of what we used to 
call "anonymous actor".  Our original specification made clear that (for 
better or worse) the answer was "yes".
I would prefer one of two formulations to resolve this question:
a) go back to the original notion that a missing actor/role attribute in 
fact designates yet one other role: a role that any intermediary could 
choose to play, and that the end point MUST assume
b) prohibit header blocks with missing role attributes.  Instead, define a 
distinguished role http://www.w3.org/2001/12/soap-envelope/role/endpoint 
to be used on headers destined for the end point, and required that the 
endpoint indeed play that role.


I have a few other more minor comments, but they are more in the range of 
editorial suggestions.  As long as they will still be accepted for 
consideration later, I would be prepared to adopt your proposed rewording 
in the meantime as long as the issues above are resolved first. 

Again, I think you have taken a significant step forward.  Thank you!

Noah Mendelsohn                              Voice: 1-617-693-4036
IBM Corporation                                Fax: 1-617-693-8676
One Rogers Street
Cambridge, MA 02142
Received on Wednesday, 6 February 2002 14:46:14 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 22:01:18 UTC