Re: Comments/Issues on Part 1

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