RE: i009 - mustIgnore rule for multiple To, ReplyTo, etc.

Paul Downey writes

>> The difficulty arises in identifying which of a 
>> repeated set of 'To' elements should be 
>> processed and which should be ignored given 
>> SOAP header is an unordered bag of informational items.

A couple of caveats before responding:

1. I haven't been following this discussion in the large...I'm just replying 
to the point above somewhat out of context.  Don't try to read into this 
response any suggestions as to what you should do regarding "To:, 
ReplyTo:, etc.":  I'm only trying to clarify how SOAP works in case it's 
helpful to you.

2. I'm inferring that since this is a public list, non-WG member 
contributions are OK.  If not, please say so and accept my apologies for 
intruding.

Anyway, the above quote from Paul somewhat mischaracterizes SOAP.  Here's 
my understanding of how SOAP works:

* A SOAP envelope is an infoset.  The elements in an Infoset are by 
definition ordered.  So, the header blocks do have an order. 

* From Section 2.6 of the SOAP Recommendation:

"The processing of one or more SOAP header blocks MAY control or determine 
the order of processing for other SOAP header blocks and/or the SOAP body. 
For example, one could create a SOAP header block to force processing of 
other SOAP header blocks in lexical order. In the absence of such a 
controlling SOAP header block, the order of header and body processing is 
at the discretion of the SOAP node. Header blocks MAY be processed in 
arbitrary order. Header block processing MAY precede, MAY be interleaved 
with, or MAY follow processing of the SOAP body. For example, processing 
of a "begin transaction" header block would typically precede body 
processing, a "logging" function might run concurrently with body 
processing and a "commit transaction" header block might be honored 
following completion of all other work."

So, you can at least in principle achieve controlled ordering of 
processing of SOAP header blocks.  Now, whether most of the widely 
deployed implementations of SOAP make it easy to achieve such control is a 
different question. 

I'm not recommending one approach or another for ReplyTo and friends, but 
just pointing out that the SOAP recommendation provides the option:  if 
you want to say in the specification for some SOAP header block:  "all 
occurrences of blocks with this QName must be processed in document order 
", the SOAP Rec. says you can do that.  Similarly you can say:  "When 
header block p:doInOrder is present, then all other header blocks must be processed in order."  Maybe a good idea or maybe 
not, but the Recommendation allows it.

Historical note:  the existence of these options is not an accident.  We 
worked for a long time in the XMLP workgroup to figure out a way to 
provide controlled ordering of header processing without putting an 
elaborate control language into SOAP.  The solution we adopted was to 
require that all mustUnderstand attributes be checked before any headers 
are processed;  this was done specifically so that if any such header attempts to control the order of processing, you'll be 
sure to find it and check that you understand it before doing anything 
else in the wrong order.  So, the "doInOrder" header can, in principle, 
appear anywhere in the list of header blocks.  You and anyone else can now 
invent your own header blocks to control header ordering in any simple or 
complex manner that you desire, mark them mU="true", and have fun.  Of 
course, the hard part is convincing the industry that your approach is 
sufficiently interesting that everyone should indeed understand your 
header.  If they  don't, your message will be safely rejected before any 
work is done in the wrong order.

--------------------------------------
Noah Mendelsohn 
IBM Corporation
One Rogers Street
Cambridge, MA 02142
1-617-693-4036
--------------------------------------

Received on Tuesday, 11 January 2005 19:04:44 UTC