RE: [R2xx] Application of XP Requirements to SOAP 1.1

Vidur,

Good set of comments - few of mine inline...
 
> Issue RPC1: The target (program, service or object) URI is 
> pushed down 
> to the protocol binding and is not represented in the 
> envelope instead. 
> While this does not conflict with the requirements, I believe it's an 
> important (and possibly debatable) decision. This decision precludes 
> sending an RPC invocation through an intermediary that uses different 
> protocol bindings for sending and receiving XP messages.

I absolutely agree that it is an important decision - and it ties into
similar discussion that we have had on the list before [10]. However, I
am not sure I agree with the notion that because one can take advantage
of a binding that this precludes adding information like the destination
in the SOAP message as well in order to support the "multi-hop" scenario
that I think you hint at.
 
> Issue RPC2: The SOAP 1.1 spec uses words like "object" and 
> "method" to 
> refer to the end-points of an RPC operation. More generic words (or 
> better qualification of these terms) that do not bias the 
> reader towards 
> expectations of full-fledged object systems on both sides are 
> necessary.

I agree
 
> Issue RPC3: The requirements state that the "procedure or 
> method to be 
> called" should also be represented using URI syntax. I 
> believe this is 
> an error in our document - the requirements should place no 
> restrictions 
> on the form of a procedure or method name.

I think this is a slightly broader issue than for the RPC section. The
notion of what constitutes a name is one of the great and bottomless
ratholes ;) and what I think the requirement is trying to indicate is
that whatever the name, it had better be able to be serialized into a
URI in some capacity in order for the XML protocol to work well with
other parts of the Web.
 
>     "2.Enable support for matching response messages to request
>      messages for cases in which matching is not provided by the
>      underlying protocol binding."
>
> Section 7.2 states that a transaction ID is an example of the 
> use of a SOAP header element.
> 
> Issue RPC4: This does not seem to be a normative part of the 
> specification and no rules are placed on the form of such a 
> transaction ID.

I agree that there is no message correlation mechanism in SOAP/1.1 but I
am wondering whether this is in fact not a very common thing that we
could imagine somebody to off and define. I think the main question is
whether SOAP "enables support" for this, no?
 
> R201
> 
>     "The RPC conventions within the XML Protocol should use the Data
>      Representation model discussed in section 4.5 to represent
>      parameters to a call in the request message and results of
>      the call in the reply message."
> 
> A method invocation is modeled as a struct. Parameters and 
> results are 
> modeled as accessors on the struct. The concepts of "struct" and 
> "accessor" are loosely described in Section 5 [3] of the 
> specification.
> 
> Issue RPC7: SOAP 1.1 describes its notion of a "data model" 
> in a section 
> describing an encoding system. The notion of a data model should 
> probably be separated from the actual physical representation.

I agree (I can say that it was the intent to separate the model from the
physical representation -- whether it came across that way is another
matter.

Thank you!

Henrik

Received on Wednesday, 31 January 2001 14:04:02 UTC