- From: Christopher Ferris <chris.ferris@sun.com>
- Date: Tue, 04 Dec 2001 13:54:50 -0500
- 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