W3C home > Mailing lists > Public > xml-dist-app@w3.org > November 2002

RE: Issues 368 and 369 Proposal

From: Henrik Frystyk Nielsen <henrikn@microsoft.com>
Date: Wed, 6 Nov 2002 11:31:41 -0800
Message-ID: <68B95AA1648D1840AB0083CC63E57AD6096E7CE5@red-msg-06.redmond.corp.microsoft.com>
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 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 7 December 2009 10:59:11 GMT