Re: Comments on a read through of part 2

Noah, thanks for your further comments. I have worked on section 4; Gudge is
working on sections 2 and 3.

Jean-Jacques.

Noah Mendelsohn/Cambridge/IBM wrote:

> Most significant comments
> -------------------------
> <snip/>
> * section 4.0 paragraph 2: I suggest adding a sentence to the end of the
> paragraph that would say: "The encoding specified must support the "struct"
> and/or "array compound" value constructions from the SOAP data model [ref
> to SOAP data model}."

Added sentence.

> Or, if you want to be less subtle: "The encoding
> specified must support the SOAP data model [ref to SOAP data model}."
> Also:  there is a more or less duplicate statement at the end of section
> 4.1.  Maybe the duplication should be eliminated?

Deleted paragraph.

> If not, then perhaps
> that paragraph also should say "However, any encoding used MUST support the
> SOAP data model."
>
> * Section 4.0: in the list of things needed to invoke an RPC: I suggest
> replacing "The URI of the target SOAP node" with "The binding-specific
> address of the target SOAP node".  While use of URI's is no doubt
> encouraged for addressing SOAP messages, the means of addressing is the
> business of the binding, not of RPC.

Replaced sentence.

> * Section 4.0: also in the list of things needed to invoke an RPC: I
> suggest removing the item that says "An optional procedure or method
> signature".  This is really a slippery slope and primarily the business of
> specifications like WSDL.  We could replace this with "The identities
> (which may be either positional or by name) and values of any arguments to
> be passed."

Replaced sentence, and deleted the next item ("The parameters to the procedure
or method").

BTW, why don't we similarly list the information returned by an RPC request?
New issue?

>  Now it's clear that description languages aren't our business:
> we just need to know what to pass in this message.
>
> * Section 4.0: should be RPC section mention any dependence on the req/resp
> MEP?  I think so.  New issue?

+1

> Moderate significance
> ---------------------
> <snip/>
> * Section 4.2:
> <original>
> Additional information relevant to the encoding of an RPC invocation but
> not part of the formal procedure or method signature MAY be expressed in
> the RPC encoding. If so, it MUST be expressed as a header block.
> </original>
> <suggested>
> Additional information relevant to the encoding of an RPC invocation but
> not part of the formal procedure or method signature MAY be expressed in an
> envelope carrying an RPC invocation or response.  Such additional
> information must be expressed as SOAP header blocks.
> </suggested>

Replaced, w/ s/must/MUST/

> Minor and editorial
> -------------------
> <snip/>
> * Section 4.1: "The invocation is viewed as a single struct or array
> containing an outbound edge for each [in] or [in/out] parameter" ===>"The
> invocation is represented by a single struct or array containing an
> outbound edge for each [in] or [in/out] parameter"

Done.

> * Section 4.1: "The response is viewed as a single struct or array
> containing an outbound edge for the return value and each [out] or [in/out]
> parameter. " ===> "The response is represented by a single struct or array
> containing an outbound edge for the return value and each [out] or [in/out]
> parameter. "

Done.

> * Section 4.3: "The SOAP RPC Representation introduces additional SOAP
> fault subcode values to the fault codes described in [1] section Fault
> Codes <soap12-part1.html>. " ====> "The SOAP RPC Representation introduces
> additional SOAP fault subcode values to be used in conjunction with the
> fault codes described in [1] section Fault Codes <soap12-part1.html>. "

Replaced.

> Also, a period is missing at the end of this paragraph.

Added.

> * Section 4.3: suggestion: "A fault with a value of "env:Sender" for
> faultcode and a value of "rpc:ProcedureNotPresent" for subcode MUST be
> generated when the receiver cannot find the procedure specified." ===> "A
> fault with a value of "env:Sender" for faultcode and a value of
> "rpc:ProcedureNotPresent" for subcode MUST be generated when the receiver
> does not support the procedure or method specified."

Replaced.

>  I don't think we want
> to suggest anything that has to do with the means by which a server
> resolves or "finds" the procedures that it is asked to invoke.   Also:  the
> rest of the spec uses the term "procedure or method", so I added that.
>
> * Section 4.3: "In all cases the values of the detail and faultstring
> element information items are implementation defined. They MAY be specified
> by some external document." ====> "In all cases the values of the detail
> and faultstring element information items are implementation defined.
> Details of their use MAY be specified by some external document." Though
> the intention is clear, I believe that gramatically the antecedent of
> "They" was ambiguous.

Done.

> (Also, I'm still not very comfortable with the term
> "external document", but don't have any bright ideas for alternatives at
> the moment).

"external document" ====> "other specifications"?

Thanks again.

Jean-Jacques.

Received on Wednesday, 10 April 2002 06:09:16 UTC