Re: Comments/Issues on Part 1

Thanks on #1.
On #2, yup, I think that is along the lines I was thinking.
There's something about the wording in the spec (or perhaps
it was the way I read it) that made it seem like a 1.2
Node MUST reject a 1.1 message rather than accept it but
use 1.1 processing semantics.  Section 4.1.2, to me,
says a 1.2 Node can ONLY accept the 1.2 version string.
It doesn't say it can accept 1.1 or 1.2 but must make sure
that it follows the appropriate processing model based on
the version string.  Perhaps if we merged section 4.1.2
and versioning appendix into one section it would clear things
up for me.  Are there plans to do this?

thanks,
-Dug


Hugo Haas <hugo@w3.org>@w3.org on 10/17/2001 08:54:25 PM

Sent by:  xml-dist-app-request@w3.org


To:   xml-dist-app@w3c.org
cc:
Subject:  Re: Comments/Issues on Part 1



* 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 Thursday, 18 October 2001 07:27:48 UTC