- From: Hugo Haas <hugo@w3.org>
- Date: Mon, 15 Oct 2001 22:48:38 -0400
- To: xml-dist-app@w3c.org
Doug, 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. > [issue - editorial] > Section 2.5 - bullet #1 > Generate a single SOAP MustUnderstand fault (see > 4.4.2 MustUnderstand Faults) if one or more SOAP blocks > targeted at the SOAP node are mandatory and are not understood > by that node. If such a fault is generated, any further processing > MUST NOT be done. > Should we make it clear that we mean "understood" and not necessarily > "succefully processed" ? For example, what if the body contains an > RPC and that service isn't deployed - in this case the block was > understood but not able to be successfully processed. This might > just be getting a bit picky so if none of the editors see a problem > with the current text, I'm ok with dropping the issue. I believe that understanding a SOAP header is sufficiently defined in section 2.4[1]. > [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. > [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. > [issue - editorial] > Section 4.2.1 - Example: Example header with a single header block > We use: mustUnderstand="1" but in the text(sec 2.4) we say it > should be "true". It is "true" in the boolean, canonical meaning of mustUnderstand. "true" can be "1" or "true". I believe that this is ok. 1. http://www.w3.org/TR/2001/WD-soap12-part1-20011002/#muprocessing -- Hugo Haas - W3C mailto:hugo@w3.org - http://www.w3.org/People/Hugo/ - tel:+1-617-452-2092
Received on Monday, 15 October 2001 22:48:38 UTC