W3C home > Mailing lists > Public > xml-dist-app@w3.org > December 2001

Re: Proposed Edits to "Framework" spec for header/body distinction.

From: <noah_mendelsohn@us.ibm.com>
Date: Tue, 4 Dec 2001 19:57:50 -0500
To: chris.ferris@sun.com
Cc: xml-dist-app@w3.org
Message-ID: <OFC9643D14.EB907B8E-ON85256B19.0004F78E@lotus.com>
Good, I'm glad we're so close to agreement.  In general, I don't have any 
technical problems with the directions you suggest.   For the most part, I 
would view your suggestions as editorial, implying that the editors should 
be the ones to decide whether wordsmithing is to be proposed to the group. 
 Indeed, I think a few things that caused you concern were in areas I 
didn't touch. 

So, my suggestion would be:  let's see whether the rest of the WG is 
generally comfortable with the proposed direction, as you seem to be. 
Let's then collect all the proposed editorial changes and rewordings, let 
the editors have a go at deciding which ones have merit and come up with 
an editors' proposal. 

FWIW, I don't honestly feel that your proposed additional step #2 is 
necessary.  The original wording of:

"Generate a single SOAP MustUnderstand fault (see 4.4.2 MustUnderstand 
Faults) if one or more SOAP header blocks targeted at the SOAP node are 
mandatory and are not understood by that node."

seems to cover it in a way that is more compact, and more in a declarative 

Regarding your suggestion of:

>> A SOAP node MAY choose to ignore the processing implied by a SOAP header 
block targeted to it butnot identified as mandatory.

I think I might make that "A SOAP node MAY choose not to perform the 
processing implied..." ; I parse your suggested form as "there was some 
processing that happened, but the node MAY ignore that it happened", which 
is clearly not what you intend.

Regarding removal of targeted headers:  I think we have to straighten out 
deeper issues regarding encryption, etc.  I think your suggestion that the 
ultimate result be in the list of processing steps may be a good one.  I'm 
glad to leave that one to the editors for a proposal, once we figure out 
the real rules.

Again, I'm really pleased that we seem to be this close on the general 
direction.  Thanks much!

Noah Mendelsohn                                    Voice: 1-617-693-4036
Lotus Development Corp.                            Fax: 1-617-693-8676
One Rogers Street
Cambridge, MA 02142

Christopher Ferris <chris.ferris@sun.com>
12/04/01 03:11 PM

        To:     Noah Mendelsohn/CAM/Lotus@Lotus
        cc:     xml-dist-app@w3.org
        Subject:        Re: Proposed Edits to "Framework" spec for header/body distinction.


In general, I like the direction that this has taken. A few 
nits/comments/suggested edits follow.



SOAP header block 
A syntactic construct or structure used to delimit data that logically 
constitutes a single computational unit as seen by a SOAP nodewithin the SOAP H eader. SOAP header blocks are direct children of the 
SOAP Header ( 4.2 SOAP Header ) or Body (4.3 SOAP Body ) element information items. The type of a SOAP header block is identified 
by the fully qualified name of the outer element for the block, which 
consists of the namespace URI and the local name. A block encapsulated within the SOAP header is called a header block and a 
block encapsulated within a SOAP body is called a body block.

there can be only one SOAP Header element, so the phrase "within a SOAP 
header" is somewhat
ambiguous IMO.

SOAP header 
A collection  of zero or more SOAP header blocks which may be targeted at 
any SOAP receiver within the SOAP message path.

SOAP body 
A collection  of zero or more element information items targeted at the 
ultimate SOAP receiver within the SOAP message path.

SOAP fault 
A special SOAP block which contains fault information generated by a SOAP 

Not sure what to do about this last bit. Since there is no longer a term 
SOAP block, what is
the SOAP:Fault? Should it be described as" a "special element information 

1.     Determine the set of roles in which the node is to act.   The 
contents of the Envelope, including header blocks and the body,MAY be 
inspected in making such determination.  [[?this changegoes beyond my 
mandate, but I think it deals cleanly and effectively with the concern 
raised by Doug.  We would need a vote of the group to accept this 
change?it's completely separate from all the others?Noah]]

I've always felt that there was a missing step here. Specifically 
something along the lines of:
2. Identify all targeted SOAP header blocks that are mandatory.

The reason that I believe this step to be necessary is to allow for the 
likes of the "processing order" header described elsewhere in the spec. It 
seems reasonable to me that this be a REQUIRED step in the process that 
MUST preceed processing. If we are to expect that any SOAP processor will 
be capable of handling such a case as the "process order" header, then 
clearly, the processor needs to be capable of predetermining if indeed 
there is such a header that is going to (possibly) alter the processing of 
the message. Granted, this doesn't preclude the case whereby a SOAP 
processor would encounter such a SOAP header block and rollback all of the 
processing to that point and begin anew using the semantics implied by 
such a header.
1.3.         Identify any SOAP header blocks targeted at the SOAP node that 
are mandatory and that are not understood by that node and generate a 
single SOAP MustUnderstand fault (see 4.4.2 MustUnderstand Faults ) . If such a fault is generated, any further processing MUST NOT be 
done.  Faults relating to the existence or contents of the body MUST NOT 
be generated in this step.

I have never been comfortable with the wording of the above step that had 
previously begun: "Generate a single SOAP Fault..."

4.     Processall SOAP header blocks targeted at the node and, in the case 
of the ultimate recipient, the SOAP body.
A SOAP node MUST process all SOAP header blocks targetted at to it. A SOAP node MAY choose to ignore the processing implied by a SOAP 
header block targeted to it butnot identified as mandatory.

The change above is to make it clearer as to what the MAY refers to. IMO, 
the MAY applies to the node's choice to ignore a non-mandatory block which 
implies that unless it has chosen to ignore it, it will be processed. 
[NOTE: should there or is there an issue related to clarification of what 
it means to "process" a SOAP header block? 

5. Remove all SOAP header blocks targeted at the SOAP node (whether they 
were processed or ignored) if the message is to be further relayed along 
the SOAP message path.
I'm uncomfortable with having this last step in the process lost in the 
lengthy prose that ensues. 

noah_mendelsohn@us.ibm.com wrote:

I sent this out this morning, and it didn't get into the archive.  Perhaps
it was because of the three large file attachments.  This time, I'm trying
one zip file.

====Original note follows=======

The attached files fulfill the action item that I took at the ftf to
prepare proposed edits to cover the new decisions on header body
distinction.  I've supplied three forms: HTML with and without "diffs", 
the base MS word file on which I did the edits.  The presumption is that,
if any of these changes are adopted, the editors will cut/paste them into
the base specification documents.   It's for David to say, but I think
we'll be discussing this on the Wed call.  The changes are significant
enough that I suggest you take 15-20 minutes over the next couple of days
to review them.  The main changes are in chapter 2, and in chapter 4
(changes in chapter 4 are mainly to delete text that has been merged into
chapter 2.)  The "diffs" are not 100% reliable, but they should be a good
guide to where I made changes.

I suggest reading without the diffs first (or turn off change tracking in
Word), as they chop up the text.  If you're worried about how much I
changed, then go back to the diffs.

As agreed at the ftf, I've also made some proposals that go beyond the
basic header/body distinction, as all these edits are somewhat
interrelated.  The following notes explain what I've done (they're also in
the documents).

At the Burlington FTF I took an action item to draft the changes that 
reflect our agreements on Body processing.  In trying to do this, I've
realized that the changes hit several parts of the document, so I've
entered them as revisions to the editors copy of the Framework.

Notes by me are in this orange color (you won't see the orange if you're
looking at a copy with "diffs" - the diffs generally show as green
).  The
actual proposed changes are marked with MS word change tracking?Word users
can see "the diffs" by turning on change highlighting.  I'll supply HTML
with and without diffs.

If you're reading the HTML versions, you'll notice that Word has done some
random paragraph formatting during the conversion.  The intention is that
the editors will copy and paste text from this draft into their base
version, and will update paragraph formatting as necessary.   You should 
able to make out what's going on.  I have no idea how this all looks in
Netscape, but I presume something more or less legible will show up.  If
not, let me know and I'll send PDF.

Some decisions I've made in doing this work:

* The primary purpose of this draft is to implement the action item
assigned to me at the FTF regarding header and body elements. The goal is
to make clear that body is not symmetric with header, and that the 
receiver can us
e a variety of means to determine the structure and
processing rules for the body.

* As suggested by several WG members, the term "Body Block" is gone.  We
now have "Header Block" and "Body"

*At Mark Hadley's request, and approved at the ftf, I have done a bit of
the moving that we agreed from chapter 4 to 2.  The editors must still 
responsibility for ensuring that they are comfortable with these
suggestions, and if so, for carrying them forward to the WG as formal

I took the liberty of making some other changes that go a bit beyond my
mandate, but that seemed best done as part of the same editing pass.  All
of these therefore should be viewed as proposals from me?there is no
obligation on the part of the group to adopt them.  If the group 
I think it is clear how to revert back to the status quo in each case.
Some of these probably should have corresponding issues openned.  I've
marked them (i

*(issue?) I've taken the liberty of putting in a placeholder that rules 
actor="" (null string).  We should really open an issue to resolve this.
The question is:  if we were to allow the null string, is that different
from a missing actor (the original spec described a missing actor as
referring to the  ultimate receiver, but said nothing about actors with a
null string.)

*(issue) I have taken the liberty of flagging a few areas where I noticed
other issues, some of which may or may not be recorded in the issues list.
For the most part, these are not intimately bound to my action item, and
can be ignored if the WG prefers.  That said, I would recommend that we
review the issues list and make sure that all of them are

*(issue) we've been vagure in our terminology and references to the schema
spec regarding our use of schema datatypes.  The schema spec distinguishes
value from lexical space,
 yet we do not clearly distinguish our use of the
two in, e,g. modelling the value of boolean attributes.

* I put in a third step in the processing model (it actually comes first),
to deal with the concern of Doug and others that we were unclear on 
you can look at the message to determine what roles to play.  I know I
fought this change, and we decided to put it in the primer, but this is a
proposal to put it in this document after all.  It's a single bullet in
(what's now) chapter 2.6, and is easily deleted.  We should have a formal
poll to determine whether this proposal is indeed acceptable.

Hope this is helpful.

(See attached file: NoahBodyHeaderChanges.zip)

Noah Mendelsohn                                    Voice: 1-617-693-4036
Lotus Development Corp.                            Fax: 1-617-693-8676
One Rogers Street
MA 02142
Received on Tuesday, 4 December 2001 20:08:51 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 22:01:17 UTC