- From: <noah_mendelsohn@us.ibm.com>
- Date: Wed, 6 Nov 2002 16:38:29 -0500
- To: "Henrik Frystyk Nielsen" <henrikn@microsoft.com>
- Cc: "David Fallside" <fallside@us.ibm.com>, xml-dist-app@w3.org
My concern was raised in part by the sentences: > That is, an implementation designed to be a SOAP sender > MUST implement all mandatory requirements to SOAP > senders, a SOAP message MUST fulfill all mandatory > requirements to SOAP messages and so forth. This implies there is such a thing as a complete SOAP sender (and I presume intermediary, receiver as well.) Maybe we could do something like: <NRM_revision_of_HFN_revised_proposal> 1.@@ Conformance This specification describes certain data formats, as well as rules pertaining to the correct generation, exchange, and processing of messages using those formats. This specification does NOT mandate the scope of any particular implementation, except insofar as it requires that no implementation violate provisions indicated as mandatory (I.e. those that the SOAP specification stipulates as "MUST" be observed, per RFC 2119.) Indeed, the SOAP specification applies not just to sending and receiving software, but to a broad range of other hardware and software system that generate and manipulate SOAP message Infosets. Thus, in order for an implementation to claim conformance with the SOAP 1.2 specification, it MUST correctly implement all mandatory ("MUST") requirements expressed in Part 1 of the SOAP 1.2 specification, insofar as those requirements are pertinent to the activity being performed. For example, an implementation designed to be a SOAP sender MUST implement all mandatory requirements pertinent to the supported sending activities. Note, however, that there is no requirement that such sending software (or hardware) be general purpose. A special purpose controller, a traffic light for example, might generate a very limited set of SOAP messages (e.g. it might have no occasion to ever send a SOAP Header); such a controller is conformant if and only if it correctly implements the mandatory requirements pertinent to the messages that it does send. An implementation MAY implement any number of the Adjuncts specified in Part 2 of the SOAP 1.2 specification. (Note there is no conformance associated with the convention for describing features and bindings [ref]). The implementation of an Adjunct MUST implement all of the pertinent mandatory requirements expressed in the specification of the Adjunct to claim conformance with the Adjunct. SOAP 1.2 can be used as the basis for other technologies that provide richer or more specialized services. To be conformant with SOAP 1.2, the specifications and implementations for such other technologies must be consistent with the pertinent mandatory requirements of {ref to SOAP part 1). Rules for conformance with such new specifications are beyond the scope of the SOAP 1.2 specification; it is recommended that specifications for such technologies provide the appropriate conformance rules. SOAP 1.2 is designed to enable at least the usage scenarios described in SOAP Version 1.2 Usage Scenarios [ref], and possibly other scenarios. Informal descriptions showing XML representations of concrete SOAP messages used in some common scenarios are provided in SOAP Version 1.2 Part 0: Primer [ref]. </NRM_revision_of_HFN_revised_proposal> Does this help? Thanks. ------------------------------------------------------------------ Noah Mendelsohn Voice: 1-617-693-4036 IBM Corporation Fax: 1-617-693-8676 One Rogers Street Cambridge, MA 02142 ------------------------------------------------------------------
Received on Wednesday, 6 November 2002 16:39:13 UTC