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

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

From: Christopher Ferris <chris.ferris@sun.com>
Date: Tue, 04 Dec 2001 13:54:50 -0500
Message-ID: <3C0D1BFA.3010407@sun.com>
To: Jean-Jacques Moreau <moreau@crf.canon.fr>
CC: Williams Stuart <skw@hplb.hpl.hp.com>, "'noah_mendelsohn@us.ibm.com'" <noah_mendelsohn@us.ibm.com>, xml-dist-app@w3.org
Oops, you are correct.



Jean-Jacques Moreau wrote:

> Chris,
> 
> Unless I am mistaken, <![CDATA[yaddayaddayadda]> is not legal per the current
> section 4.3, part 1, or the schema at [1]:
> 
>      "The Body element information item has [...] zero or more element
>      information item children. [...] All child element information items of
>      the SOAP Body element information item are called SOAP body blocks.
>      Each SOAP body block element information item [...] MUST be namespace
>      qualified; MAY have an encodingStyleattribute information item."
> 
> Jean-Jacques.
> 
> [1] http://www.w3.org/2001/09/soap-envelope
> 
> Christopher Ferris wrote:
> 
> 
>>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 13:59:10 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 5 February 2014 22:28:13 UTC