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

+1 to use of distinguished role for endpoint

noah_mendelsohn@us.ibm.com wrote:

> 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 
> stands.)
> 
> ====
> 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
> -or-
> 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 15:44:41 UTC