RE: Issues 368 and 369 Proposal

Hopefully a more readable version. Note that this section is intended to
appear after the "Notational Conventions" section and so refs to 2119 are
not necessary.

<DF_tweak_of_HFN_tweak_of_NRM_revision_of_HFN_revised_proposal>

1.@@ Conformance

This specification describes data formats, and the rules for generating,
exchanging, and processing messages using those formats. This specification
does not mandate the scope of any particular implementation, although it
requires that no implementation violate any mandatory requirement.

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 {ref} that pertain to the activity
being performed. Note that an implementation is not mandated to implement
all the mandatory requirements. For example, a special purpose traffic
light implementation that never sends a SOAP header can claim conformance
provided that it correctly implements the mandatory requirements that
pertain to the messages it does send.

An implementation MAY implement any number of the Adjuncts specified in
Part 2 of the SOAP 1.2 specification {ref}. Note that no conformance is
associated with the convention for describing features and bindings {ref}.
The implementation of an Adjunct MUST implement all 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 claim conformance with the SOAP
1.2 specification, the specifications and implementations of such
technologies must be consistent with the pertinent mandatory requirements
expressed in Part 1 of the SOAP 1.2 specification {ref}. 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].

</DF_tweak_of_HFN_tweak_of_NRM_revision_of_HFN_revised_proposal>

............................................
David C. Fallside, IBM
Ext Ph: 530.477.7169
Int  Ph: 544.9665
fallside@us.ibm.com



|---------+------------------------------>
|         |           Noah               |
|         |           Mendelsohn/Cambridg|
|         |           e/IBM@Lotus        |
|         |           Sent by:           |
|         |           xml-dist-app-reques|
|         |           t@w3.org           |
|         |                              |
|         |                              |
|         |           11/08/2002 07:20 AM|
|         |                              |
|---------+------------------------------>
  >-----------------------------------------------------------------------------------------------------------------------------|
  |                                                                                                                             |
  |       To:       "Henrik Frystyk Nielsen" <henrikn@microsoft.com>                                                            |
  |       cc:       David Fallside/Santa Teresa/IBM@IBMUS, xml-dist-app@w3.org                                                  |
  |       Subject:  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 Tuesday, 19 November 2002 00:31:46 UTC