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

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 12:28:38 UTC