W3C home > Mailing lists > Public > xml-dist-app@w3.org > November 2002

Re: SOAP Header Element Question

From: Jean-Jacques Moreau <moreau@crf.canon.fr>
Date: Thu, 07 Nov 2002 09:47:10 +0100
Message-ID: <3DCA288E.8030409@crf.canon.fr>
To: Jacek Kopecky <jacek@systinet.com>
CC: Frank Adams-Watters <fwatters@DataStructures.com>, "'xml-dist-app@w3.org'" <xml-dist-app@w3.org>

To add to this, it is perfectly legal to have NOT have a <Header> 
element. As Jacek points out, NOT having a <Header> element or 
having a <Header> element with no header block is different from 
a syntactic POV, but equivalent from a processing model POV.

A SOAP receiver must process all the blocks targetted to it. If 
there are no blocks, whether because there is no <Header> element 
or because there is no header block doesn't make a difference 
from a processing model POV.


Jacek Kopecky wrote:
> Frank, 
> it is my view that a responder can do whatever it will as long as the
> processing rules are being followed. For example, if the request is to
> cound 
> Generally though, most responders will not differentiate between an
> empty Header element and no Header element. 
> Best regards, 
>                    Jacek Kopecky
>                    Senior Architect, Systinet Corporation
>                    http://www.systinet.com/
> On Mon, 2002-11-04 at 20:01, Frank Adams-Watters wrote: 
>>The SOAP header is defined as "a collection of zero or more SOAP header
>>blocks".  And it is an optional element in the SOAP envelope.  My question
>>is, is there any difference between not having a SOAP header, and having a
>>SOAP header with zero header blocks (and no attributes on the header
>>element)?  In other words, are receivers permitted to respond differently to
>>two such messages?  It seems to me that the answer should be "no", and that
>>the specification should say so; I can't find anywhere that it does.
>>This is admittedly a minor point.  SOAP messages with zero header blocks are
>>probably going to be quite rare.  And it would certainly be a design mistake
>>to make such a distinction, either in published semantics for a message or
>>in actual implementation of a receiver: it closes off possibilities for
>>later enhancement.  However, I still think the specification should be
>>explicit on this point.
>>I would appreciate it if someone on the committee would email me a response
>>on this; I'm not on this mailing list (and don't have sufficient interest in
>>the topic to want to be), and I may or may not eventually check in the
>>archives to see if anyone has responded.
>>Frank Adams-Watters   DataStructures
>>1300 Iroquois Dr., Ste 250   Naperville, IL  60563
>>Land of the free ... home of the brave.
Received on Thursday, 7 November 2002 03:48:04 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 22:01:22 UTC