RE: Issues 368 and 369 Proposal

This is fine with me, thanks.  I agree it's a bit long, but since we've 
had so much trouble getting our reviewers to understand the flexibility 
inherent in the specification, I think this is probably a good approach. 
Thanks.

------------------------------------------------------------------
Noah Mendelsohn                              Voice: 1-617-693-4036
IBM Corporation                                Fax: 1-617-693-8676
One Rogers Street
Cambridge, MA 02142
------------------------------------------------------------------







"Henrik Frystyk Nielsen" <henrikn@microsoft.com>
Sent by: xml-dist-app-request@w3.org
11/06/02 11:39 PM

 
        To:     <noah_mendelsohn@us.ibm.com>
        cc:     "David Fallside" <fallside@us.ibm.com>, <xml-dist-app@w3.org>
        Subject:        RE: Issues 368 and 369 Proposal
Categories: 
 






I think this is a reasonable direction although a bit on the long side.
I only have two friendly amendments:

1) I would suggest deleting the sentence "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." as I don't think it carries a lot of information
compared to the rest of the text.

2) Rather than using the terms "software", "hardware", and "controller"
I would simply use the term "implementation" as SOAP is inherently
platform independent.

That is, something like this

<HFN_tweak_of_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.)

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 an implementation 
be general purpose.  A special 
purpose implementation, 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 an implementation 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].
</HFN_tweak_of_NRM_revision_of_HFN_revised_proposal>

How does this sound?

Henrik

Received on Friday, 8 November 2002 10:27:16 UTC