Re: Comments/Issues on Part 1

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