Re: Issue 292: Analysis and proposal

 Noah,
 I'm a bit nervous about the part I've left of your message below.
Please see my comments.

                   Jacek Kopecky

                   Senior Architect, Systinet Corporation
                   http://www.systinet.com/


On Sat, 2002-09-07 at 01:29, noah_mendelsohn@us.ibm.com wrote:
> I know this seems a bit tricky, but it's really quite natural to implement,
> and it does what one wants I think.  Specifically:  there's no way that one
> of the faults was labeled MUST, but you didn't get any fault at all.  If
> any fault was labeled "MUST", then you'll definitely get some fault.   For
> the reason cited in the discussion above, the fault you get may or may not
> be one of the MUST faults, as your implementation may hit a SHOULD or MAY
> fault before it even notices that there would have been a MUST, but sooner
> or later it will definitely fault.

If the spec says that if something happens a particular fault MUST be
generated, the above text contradicts the MUST. I think a reader of the
spec will expect BadArguments even in MissingID cases if the RPC
convention is used.

I agree that what I proposed would have effect on the implementations,
but (having implemented SOAP myself) I honestly think this effect does
not outweigh the seriousness of the contradiction above.

Now I think what you want to achieve can be achieved nevertheless, only
not as simply as you're proposing. RPC always uses SOAP Data Model,
therefore it can say in the RPC Faults section that if SOAP Data Model
encoding deserialization results in a fault, that fault MAY be generated
instead of any of the RPC faults, e.g. when efficiency concerns are
present. Either this, or relax the MUST to a SHOULD and the issue goes
away.

Hope my point is clear,

Jacek

Received on Sunday, 8 September 2002 20:38:27 UTC