- From: Doug Davis <dug@us.ibm.com>
- Date: Tue, 16 Oct 2001 07:09:47 -0400
- To: xml-dist-app@w3c.org
Hugo wrote: >I have entered all your comments in the issues list, except for the >ones below (147 to 160). >* Doug Davis <dug@us.ibm.com> [2001-10-10 07:54-0400] >> [issue - editorial] >> Section 2.3 - 1st paragraph >> We refer to the (implicit or explicit) value of the SOAP actor >> attribute as the SOAP actor for the corresponding SOAP block >> (either a SOAP header block or a SOAP body block). >> "a" body block should be "the" body block - isn't the entire body >> targeted? >I think that this is correct. "The corresponding SOAP block" is either >_a_ SOAP header block (i.e. a child element of the Header element) or >_a_ SOAP body block (i.e. a child element of the Body element). >I have not added an issue for this one. I've always viewed the body as a single XML block - yes there are multiple child elements of the Body element, but when the ultimate destination processes the body doesn't the SOAP spec assume that the "entire" body is targeted for that node? If so, then it seems like it should be "the" body block not "a" body block. But, it's not a huge thing - people will probably get the point of it either way. >> [issue - editorial] >> Section 2.5 - last paragraph >> Additional SOAP header blocks MAY be inserted at any point in >> the SOAP message, and such inserted SOAP header blocks MAY be >> indistinguishable from one or more just removed (effectively >> leaving them in place, but emphasizing the need to reinterpret >> at each SOAP node along the SOAP message path.) >> We need to say where they are placed since we went out of our >> way to say that the order of "untouched" blocks MUST NOT change >> or we could just say it doesn't matter - but we should probably >> say something. >Isn't this what the specification says: "blocks MAY be inserted at any >point"? >Sorry, I might not be understanding what you meant. Oops! 8-) >> [issue - editorial] >> Section 4.1.2 >> SOAP does not define a traditional versioning model based on >> major and minor version numbers. If a SOAP message is received >> by a SOAP node in which the document element information item >> does NOT have a local name of Envelope and a namespace name of >> http://www.w3.org/2001/06/soap-envelope the SOAP node MUST >> treat this as a version error and generate a VersionMismatch >> SOAP fault (see 4.4 SOAP Fault). A SOAP VersionMismatch fault >> message MUST use the SOAP/1.1 envelope namespace >> "http://schemas.xmlsoap.org/soap/envelope/" >> (see A Version Transition From SOAP/1.1 to SOAP Version 1.2). >> >> This is wrong - this says that if you also support v1.1 you're >> not SOAP compliant. >I believe that this is correct. If you receive a SOAP/1.1 message, >then you should follow the SOAP/1.1 specification and it will indeed >tell you that it's ok. If you are a SOAP Version 1.2 processor >receiving a SOAP/1.1 message, you should indeed fault. >Please note the new text after resolution of issue 128: >SOAP does not define a traditional versioning model based on major and >minor version numbers. If a SOAP message is received by a SOAP 1.2 >node in which the document element information item does NOT have a >local name of Envelope and a namespace name of >http://www.w3.org/2001/09/soap-envelope the SOAP node MUST treat this >as a version error and generate a VersionMismatch SOAP fault (see 4.4 >SOAP Fault). A SOAP VersionMismatch fault message MUST use the >SOAP/1.1 envelope namespace >"http://schemas.xmlsoap.org/soap/envelope/" (see A Version Transition >From SOAP/1.1 to SOAP Version 1.2). >It talks explicitely about SOAP Version 1.2 nodes. I'm confused - so we're not going to allow a SOAP 1.2 processor to accept a SOAP 1.1 message? It MUST fault? If so, that's not much of a versioning scheme. I thought at the f2f in France we decided that a 1.2 processor could either Fault (if it only wants to accept 1.2 msgs) OR it could accept it and use the 1.1 version processing model. I don't remember us agreeing that it MUST fault. Or, are you saying that at a higher level something looked at the versioning URI and decided to call either a 1.1 or 1.2 processor so a 1.2 processor should never see a 1.1 message? thanks! -Dug
Received on Tuesday, 16 October 2001 07:10:19 UTC