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

Stuart,

But the processing of SOAP "blocks" is defined/determined
by the SOAP spec whereas the processing of Body element
info items is not covered by, prescribed by or even
hinted at by the SOAP spec except for the case of the
part2 RPC which provides one way of handling the contents
of the SOAP Body. As for the messaging framework, we really
have nothing to say about how the contents (if any) of
the Body are processed. The contents of the SOAP body
could be a CDATA section. That looks nothing like, nor
is it processed in any way like a SOAP block.

<S:Envelope xmlns:S="http://www.w3.org/2001/...">
   <S:Body>
     <![CDATA[yaddayaddayadda]>
   </S:Body>
</S:Envelope>

The above is a perfectly valid, if not very useful
use of a, SOAP message yet there is no element name and
there is no namespace, hence it isn't a SOAP block.

Cheers,

Chris
Williams, Stuart wrote:

> Hi Noah,
> 
> Basically I'm fine with what you've done - thanks. 
> 
> Regarding:
> 
> 
>>* As suggested by several WG members, the term "Body Block" 
>>is gone.  We now have "Header Block" and "Body"
>>
> 
> More of a minor niggle really... I do find it uneven to talk of header
> blocks and the SOAP Body. The SOAP Header contains blocks, the SOAP body
> contains blocks. I think that refering soley to the body feels awkward in
> some places, for example, the new 2.5 opens with:
> 
> "A SOAP body consists of zero or more namespace qualified element
> information items, which are the immediate children of the <Body> element
> information item.  SOAP mandates no particular structure or interpretation
> for such body elements:  the ultimate recipient node MUST correctly process
> the body element(s) it receives, but SOAP provides no standard means for
> specifying the processing to be done.  When multiple body elements are
> present, such elements MAY represent a single unit of work to be performed,
> MAY represent multiple separate processing steps, possibly but not
> necessarily in order, MAY represent data or metadata, MAY convey a mixture
> of work units and data, etc."
> 
> This effectively recreates the term 'SOAP body blocks' as 'body elements'
> which of course is not to be confused with the phase "SOAP Body element
> information item" :-).
> 
> Not a big deal for me... but it doesn't feel that comfortable (to me).
> 
> Regards
> 
> Stuart
> 
> 
>>-----Original Message-----
>>From: noah_mendelsohn@us.ibm.com [mailto:noah_mendelsohn@us.ibm.com]
>>Sent: 03 December 2001 20:51
>>To: xml-dist-app@w3.org
>>Subject: Proposed Edits to "Framework" spec for header/body 
>>distinction.
>>
>>
>>
>>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",
>>
> and
> 
>>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
>>
> would
> 
>>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 be 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 ultimate
>>receiver can use 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 take
>>responsibility for ensuring that they are comfortable with these
>>suggestions, and if so, for carrying them forward to the WG as formal
>>proposals.
>>
>>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 disagrees,
>>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 (issue?):
>>
>>*(issue?) I've taken the liberty of putting in a placeholder 
>>that rules out
>>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
>>recorded/resolved.
>>
>>*(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 whether
>>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
>>Cambridge, MA 02142
>>--------------------------------------------------------------
>>----------
>>
>>
>>
>>
>>
>

Received on Tuesday, 4 December 2001 10:04:27 UTC