W3C home > Mailing lists > Public > xmlp-comments@w3.org > June 2002

Re: SOAP 1.2 Test Suite feedback

From: Anish Karmarkar <Anish.Karmarkar@oracle.com>
Date: Wed, 05 Jun 2002 12:34:52 -0700
Message-ID: <3CFE67DC.EC1AC6FD@oracle.com>
To: Henrik Frystyk Nielsen <henrikn@microsoft.com>
CC: w3c-xml-protocol-wg@w3.org, xmlp-comments@w3.org, Ramesh Seshadri <ramesesh@microsoft.com>, Paul Cotton <pcotton@microsoft.com>, Alex DeJarnatt <alexdej@microsoft.com>, Kirill Gavrylyuk <kirillg@microsoft.com>

Comments inlined.
-Anish
--

Henrik Frystyk Nielsen wrote:
> 
> Thanks for the review,
> 
> >> * Test:T1.4.2
> >>
> >> Is the assertion in the description correct ?
> >>
> >
> >Hmm. This test got added as a result of resolution of issue 194, which
> >says that:
> >"The encoding style attribute MUST NOT appear in ANY element defined in
> >the envelope namespace"
> 
> I think it has been changed to where it MAY appear rather than where it
> MUST NOT appear. It might have been clearer by saying where it MUST NOT
> appear but I can go either way.
> 

Part 1, section 5.1.1 says:
"The encodingStyle attribute information item MAY appear on:

              1.A SOAP header block (see 5.2.1 SOAP header block).

              2.A child element information item of the SOAP Body
element information item (see 5.3.1 SOAP Body child
                Element).

              3.A child element information item of the SOAP Detail
element information item (see 5.4.5.1 SOAP detail
                entry).

              4.Any descendent of 1, 2, and 3 above.
"

As you say in your email, this does not mean that it MUST NOT appear on
Envelope, Header, Body. It seems to me that the issue resolution
requires the spec to say that it MUST NOT appear on Envelope, Header,
Body.

> >> * Test:Mark142
> >>
> >> This test shows the generation of a rpc:ProcedureNotPresent fault
> >> subcode but this is not required anymore (it is a MAY). Hence this
> >> response is not guaranteed. An equally valid response would not have
> >> this subcode.
> >>
> >
> >That is quite true. The test collection does a lot of things that are
> >not required (RPC, soap encoding are optional), but aid interop
> >implementations. It seems to me that this test would aid interop
> >implementations.
> 
> This IMO this should be clearly marked and alternatives at least called
> out.
> 

I think that is reasonable. In fact, I would like to add text to the
test collection, which calls out all the alternatives. For example, The
"Reason" string in the fault does not have to match to conform to the
test collection.

> >> * Test:standalone-test
> >>
> >> The request message has standalone='yes', this corresponds to XML 1.0
> >> [2], but SOAP 1.2 specifies "true" [3]. This has been reported to the
> >> SOAP 1.2 spec editors as a bug.
> >>
> >
> >'yes' will be changed to 'true'.
> 
> No, 'yes' was correct, it was a spec bug (which has been fixed).
> 

Got it.

> >> * Test:encodingStyle-on-env-test
> >>
> >> It is not clear what assertion is being tested by this test.
> >
> >This test got added as a result of resolution of issue 194, which says
> >that:
> >"The encoding style attribute MUST NOT appear in ANY element defined in
> >the envelope namespace"
> >
> >But I do not see this text in the latest spec.
> >Is this an issue against the spec?
> 
> Same as comment above - encodingStyle can not appear on elements
> directly defined by envelope schema.
> 
> >> Proposal for some additions to the test suite
> >> ---------------------------------------------
> >>
> >> * May want to add a test for Nested Structs.
> >>
> >
> >I think that this is a good idea. I believe SOAP builders
> >round 2 (base)
> >has a echoStruct test. This can be ported to SOAP 1.2
> >
> >> * When unsupported Content-Type is sent, the response should
> >be that of
> >> Http Error 415.
> >
> >Good idea. Will be added.
> >
> >>
> >> * When the request for an array doesn't explicitly mention
> >an ItemType
> >> attribute in it, the server should be able to handle the response.
> >>
> >
> >A test for this scenario will be added.
> 
> Great - thanks!
> 
> Henrik
Received on Wednesday, 5 June 2002 15:35:26 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 27 October 2009 08:42:27 GMT