Re: Issues 368 and 369 Proposal

Noah, I agree with your comments below (albeit it would be an 
advantage to the editors and to implementors to not have 
conforming initial senders, as it would make the spec shorter and 
easier to implement. ;-)).

More seriously, I think the statement needs to be revised.

Jean-Jacques.

noah_mendelsohn@us.ibm.com wrote:
> Just curious, anyone have further comments on the attached?  Thanks.
> 
> ------------------------------------------------------------------
> Noah Mendelsohn                              Voice: 1-617-693-4036
> IBM Corporation                                Fax: 1-617-693-8676
> One Rogers Street
> Cambridge, MA 02142
> ------------------------------------------------------------------
> 
> 
> 
> 
> 
> 
> 
> Noah Mendelsohn
> 10/14/2002 04:35 PM
> 
> 
>         To:     "David Fallside" <fallside@us.ibm.com>
>         cc:     xml-dist-app@w3.org
>         Subject:        Re: Issues 368 and 369 Proposal
> 
> 
> 
>>>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 
> (para
> 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.
> 
> <proposal>
> 1.3 Conformance
> A conforming implementation of the SOAP specification is called a SOAP 
> node
> [ref].
> 
> 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 
> may
> 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 
> messages
> used in some common scenarios are provided in SOAP Version 1.2 Part 0:
> Primer [ref].
> </proposal>
> 
> ............................................
> David C. Fallside, IBM
> Ext Ph: 530.477.7169
> Int  Ph: 544.9665
> fallside@us.ibm.com
> 
> 
> 
> Monday, October 14, 2002 6:16 AM
> To: xml-dist-app@w3.org
> cc:
> 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, 
> and
> what does it mean.
> 2. clearly state that Part I is obligatory and any adjunct from the Part 
> II
> 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.
> 
> Discussion:
> 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
> mandatory
> 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
> specifications.
> 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 
> applcations
> 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
>    specification.
>    XML Schema [2] proposes three levels of conformance by profiling the
>    specification. For the SOAP 1.2 specification, this would correespond 
> to
>    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
> 
> John
> 
> 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 Friday, 18 October 2002 04:19:14 UTC