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

Re: Issues 368 and 369 Proposal

From: <noah_mendelsohn@us.ibm.com>
Date: Mon, 14 Oct 2002 16:35:44 -0400
To: "David Fallside" <fallside@us.ibm.com>
Cc: xml-dist-app@w3.org
Message-ID: <OF1766723D.AC35BF7B-ON85256C52.00708AEF@lotus.com>

>> A SOAP node can claim to conform to the SOAP 1.2 specification when it
processes SOAP messages that conform to the SOAP message construct [see 5.
SOAP Message Construct] and according to the SOAP processing rules [see 2.
SOAP Processing Model]. 

This seems to imply that you can't have conforming initial senders, since 
they don't process messages per the Processing Model.  I don't have 
proposed text, but the spirit of what we need is:  "what you do, you do 
according to the rec."  I can't think of any one part of the 
recommendation that must in all cases be implemented by a node.  Initial 
senders and ultimate receivers seem to have relatively disjoint 
requirements;  intermediaries have requirements which overlap with both 
initial sender and ultimate receiver, but intermediaries have some 
requirements of their own.   When MEPs are considered, the 
responsibilities change further;  an ultimate receiver in request/response 
has an obligation to respond, and the originial sende waits for the 
response.   Furthermore,  use of features can, in principle, override 
quite a few of the rules that would otherwise apply to senders, receivers, 
and intermediaries.

Bottom line:  I think there's a real risk that by making a conformance 
statement we inadvertently restate the recommendation in different or more 
restrictive form.  Why do we need one?  Doesn't the recommendation speak 
for itself?  If we do need one, I think it needs to talk about the 
responsibilities of initial senders, ultimate recipient, and intermediary. 
 It needs to take account of the fact that we do not have any notion of a 
general purpose SOAP processor in any case:   traffic lights are ok. 
Furthermore,  the features you use, including MEPs (such as the ones we 
supply) can both tighten and loosen the rules.

We need to be very careful here, I think.  Thanks.

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

"David Fallside" <fallside@us.ibm.com>
Sent by: xml-dist-app-request@w3.org
10/14/2002 02:54 PM

        To:     xml-dist-app@w3.org
        cc:     (bcc: Noah Mendelsohn/Cambridge/IBM)
        Subject:        Re: Issues 368 and 369 Proposal

Here's some text to start from. It fudges exactly what is conformance 
2, sentence 1) -- awaiting the outcome of John's suggested discusion topic
-- but I think it answers the other issues. The text would be added as new
subsections into Parts 1 and 2.

1.3 Conformance
A conforming implementation of the SOAP specification is called a SOAP 

A SOAP node can claim to conform to the SOAP 1.2 specification when it
processes SOAP messages that conform to the SOAP message construct [see 5.
SOAP Message Construct] and according to the SOAP processing rules [see 2.
SOAP Processing Model]. Implementers should find the assertions and tests
described in SOAP Version 1.2 Specification Assertions and Test Collection
[ref] useful in building and testing conformant SOAP nodes. A SOAP node 
additionally implement: support for the SOAP data model [ref], the SOAP
encoding of that data model [ref], the SOAP RPC representation [ref], and
the SOAP HTTP binding, or any combination thereof, although such
implementations are not required of a SOAP 1.2 compliant SOAP node. To
briefly summarise, a SOAP node must implement Part 1 of the SOAP 1.2
specification to be compliant, and it may additionally implement any, all
or none of the adjuncts from Part 2 of the SOAP 1.2 specification although
any such implementations do not change the implementation's compliance to
the SOAP 1.2 specification.

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 
used in some common scenarios are provided in SOAP Version 1.2 Part 0:
Primer [ref].

David C. Fallside, IBM
Ext Ph: 530.477.7169
Int  Ph: 544.9665

Monday, October 14, 2002 6:16 AM
To: xml-dist-app@w3.org
From: John Ibbotson/UK/IBM@IBMGB
Subject: Issues 368 and 369 Proposal

Issue 369 and most of issue 368 seek to calrify the conformance criteria
for the SOAP 1.2 specification. The issues were raised as part of a review
of the SOAP WG documents bythe W3C QA WG.

The relevant parts of issue 368 are:
There is no dedicated Conformance section that would
1. when an implementation could claim conformance to the SOAP 1.2 spec, 
what does it mean.
2. clearly state that Part I is obligatory and any adjunct from the Part 
is optional.
   What combinations of the adjuncts in Part II are allowed.
3. State explicitly, does the implementation of the Part I that does not
use any of the adjunct of the Part II still conform to the
   SOAP 1.2 specification.

Issue 369 states that:
Embedded in the issue 368. Not clear if the implementation is required to
implement any of the adjuncts from the Part 2 in order to
conform to the SOAP 1.2 specification.

The two issues taken together raise the point that there is no clear
statement on what constitutes conformance to the SOAP 1.2 specification.
In particular:
   It is unclear when and how an implementation can claim conformance
   Whether to be conformant, part 1 of the specification is obligatory and
   part 2 is optional

Conformance is further complicated by statements made in the SOAP
Version1.2 Specification Assertions and Test Collection document [1]. In
section1 (Introduction) of that document, it states that :
"A SOAP 1.2 implementation that passes all of the tests specified in this
document may claim to conform to the SOAP 1.2 Test Suite $Date 2002/06/26
In the following paragraph, it states that conformance to the test suite
does not imply conformance to the SOAP 1.2 specification since there are
requirements in the specification that are not tested in the test suite
(for example that every legal value of a role name is accepted and all
illegal role names are
rejected). The same paragraph goes on to say that:
"An implementation may be said to be SOAP 1.2 conformant if and only if it
it satisfies the conformance requirements specified in SOAP 1.2
The W3C does not at this time provide for any comprehensive means of
testing for such conformance."
Neither part 1 or part 2 of the specification contain any statement with
respect to conformance.

The introduction also states that applications may be conformant even if
they do not implement all of the test suite. This is to support 
in special purpose
implementations such as dedicated controllers which only implement a
limited set of messages.

Proposals for discussion:
I see two starting points for WG discussion:
   If we accept that there are parts of the SOAP 1.2 specification for
   which there are no testable assertions, then we should accept that the
   set of test cases are "as close as we can test". Therefore we should
   state in the specifications part 1 and part 2 that conformance to the
   set of testable assertions is the same as conformance to the
   XML Schema [2] proposes three levels of conformance by profiling the
   specification. For the SOAP 1.2 specification, this would correespond 
   part 1 wih profiles based on part 2.

[1] http://www.w3.org/TR/2002/WD-soap12-testcollection-20020626
[2] http://www.w3.org/TR/xmlschema-1/#concepts-conformance


Emerging ebusiness Industry Architecture ,
XML Technology and Messaging,
IBM UK Ltd, Hursley Park,
Winchester, SO21 2JN

Tel: (work) +44 (0)1962 815188        (home) +44 (0)1722 781271
Fax: +44 (0)1962 816898
Notes Id: John Ibbotson/UK/IBM
email: john_ibbotson@uk.ibm.com
Received on Monday, 14 October 2002 20:19:46 GMT

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