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

Noah,

Please see below.

Cheers,

Chris

Noah Mendelsohn wrote:

> 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. 


Sounds reasonable to me.


> 
> 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 
> style. 


Well, my concern deals mostly with the style;-) The fact that it
starts out with the declarative "Generate a single SOAP MustUnderstand
Fault ..." which is not likely to be the case is awkward IMO.

If the step were phrased as I had it, or possibly :

	"In the event that one or more SOAP header blocks targeted
	at the SOAP node are mandatory, yet not understood by that
	SOAP node, generate a single SOAP ..."

The trailing "if..." is what I have trouble with in terms of
awkwardness. That's all;-)


> 
> 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.


Yes, that is certainly what I meant;-) I like the wording you
proposed.


> 
> 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.


Sounds good;-) Thanks again for taking on this task. It certainly
is an improvement over the previous state of the spec.


> 
> 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.
> 
> 
> Noah,
> 
> In general, I like the direction that this has taken. A few 
> nits/comments/suggested edits follow.
> 
> Cheers,
> 
> Chris
> 
> 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 
> node....
> 
> 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 
> item..."?
> 
> 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", 
> 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 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 
> 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 (i
> ssue?):
> 
> *(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 21:39:21 UTC