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

RE: Issues 368 and 369 Proposal

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
Message-ID: <OFA67A38CA.408EDA3D-ON85256C69.00736EA9@lotus.com>

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 GMT

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