- From: Henrik Frystyk Nielsen <henrikn@microsoft.com>
- Date: Wed, 6 Nov 2002 11:31:41 -0800
- To: <noah_mendelsohn@us.ibm.com>
- Cc: "David Fallside" <fallside@us.ibm.com>, <xml-dist-app@w3.org>
Hmm, it was the intent to indicate support for this scenario in the
sentence:
"In order for an implementation to claim conformance with the SOAP 1.2
specification, it MUST implement all mandatory ("MUST") requirements
expressed in Part 1 of the SOAP 1.2 specification necessary to implement
the functionality needed by that implementation."
and in particular "the functionality needed". That is, we don't set any
boundaries to what a "function" is. However, whatever the function is,
an implementation has to comply with it. The mention of a SOAP sender
and a SOAP message are examples of such "functions".
Henrik
>We are NOT writing a specification for one or another packaged form of
>implementation, IMO. We are specifying a protocol. The rule for an
>implementation must be: be consistent with the specification,
>no more no
>less. I'm sorry if that makes the QA folks wince, but there it is.
>
>For example, let's say I claim to have an API (think DOM) that
>creates and
>writes out SOAP envelopes. I claim our spec constrains that
>implementation, insofar as this implementation claims to write out
>"envelopes", and we give the rules for those. Nonetheless, this
>implementation is neither a sender nor a receiver. We do specify some
>specific responsibilities, such as sender, that an implementation can
>assume. Still, we have no notion of completeness, except
>insofar as that
>follows from particular rules in the recommendation. If I never send
>headers, that's fine, but if I do send them they must be as the Rec
>demands. Similarly, a receiver that sends an mU fault for any message
>with an mU header targeted to that receiver is a perfectly legal and
>useful form of SOAP implementation -- some PERL scripts are
>doing this I
>believe. It's just not a fully general purpose implementation.
>
>These are serious distinctions and I am not willing to let
>them go, unless
>of course I've misunderstood something. Thanks.
Received on Wednesday, 6 November 2002 14:32:13 UTC