- From: Hugo Haas <hugo@w3.org>
- Date: Wed, 17 Oct 2001 20:54:25 -0400
- To: xml-dist-app@w3c.org
* Doug Davis <dug@us.ibm.com> [2001-10-16 07:09-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. I see your point. Actually, that is what I realized when I was looking at issue 101 yesterday. The agenda of today's teleconference mentioned that the spec, part 1, might be clarifying the difference between SOAP header blocks and body blocks (or body block). What I noted in the processing model is that SOAP intermediaries can only act on (consume or insert) SOAP header blocks; [1] reads: Such relayed [by a SOAP intermediary] SOAP messages MUST contain all SOAP header blocks and the SOAP body blocks from the original SOAP message, in the original order, except that SOAP header blocks targeted at the SOAP intermediary MUST be removed (such SOAP blocks are removed regardless of whether they were processed or ignored). Additional SOAP _header_ blocks MAY be inserted at any point in the SOAP message [..]. Therefore, I think that the difference between header blocks and body blocks described in section 4.3.1[2] is incomplete. I think that the current text in section 2.5 suggests that blocks in the Body element are put there by the initial sender, to the attention of the ultimate receiver, and that they form a fixed set until the message reaches the final destination. I think that we should add some text to reflect this. It seems to me that blocks in the Body can only be added when the message is first built, and consumed by the ultimate receiver. Maybe I am the last person finally realizing that though. :-) I had a look at issue 137[3] which is over the same piece of text, but I think it treats a different issue: modifying blocks targetted to a different SOAP node. Therefore, I understand your argumentation about _the_ Body block, and we might want to revisit the spec about that. I will lodge an issue about that. [..] > >> [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? The second. If a processor was to support both version, I would expect it to recognize the namespace, and switch to the right piece of code: For a SOAP Version 1.2 only processor: http://schemas.xmlsoap.org/soap/envelope/ -> version mismatch with upgrade hint http://www.w3.org/2001/09/soap-envelope -> SOAP Version 1.2 processing http://example.com/ -> version mismatch For a SOAP/1.1 plus SOAP Version 1.2 processor: http://schemas.xmlsoap.org/soap/envelope/ -> SOAP/1.1 procossing http://www.w3.org/2001/09/soap-envelope -> SOAP Version 1.2 processing http://example.com/ -> version mismatch I think that this is what should/could happen according to the specs. Is that what you were expecting? 1. http://www.w3.org/TR/2001/WD-soap12-part1-20011002/#procsoapmsgs 2. http://www.w3.org/TR/2001/WD-soap12-part1-20011002/#N40069A 3. http://www.w3.org/2000/xp/Group/xmlp-issues.html#x137 -- Hugo Haas - W3C mailto:hugo@w3.org - http://www.w3.org/People/Hugo/ - tel:+1-617-452-2092
Received on Wednesday, 17 October 2001 20:54:25 UTC