Re: On the ordering of header entries

Just to make sure I understand -  

On Sun, May 20, 2001 at 08:23:31PM -0700, Henrik Frystyk Nielsen wrote:
> 
> 0) Blocks are fundamentally unordered from a processing point of view.

On the call, you read this as processing is atomic - i.e., a fault is
generated or not generated, not generated for a particular header.
Some people read this as 'ordering of headers in the message does not
indicate order of processing', but I don't think this was your
intent. Or was it?

This implies the ability of Modules to rollback their actions if a
later module faults (as Noah discussed).


> 1) A SOAP intermediary MUST NOT reorder header entries. It may add
> header entries anywhere in the message
> 
> 2) Dependencies are indicated in one of two ways:
> 
> 	* Simple XML encapsulation in which the SOAP header is somewhat
> 	  out of the picture as the encapsulation happens with a
> 	  header entry

This relies on the XML structure, including ordering of elements, to
determine processing order.


> 	* By referring to other header entries using links. In this case
> 	  we can say that such links SHOULD point *forward* in the
>         message

This relies on the traversal of a graph, described by module
attributes (for example) to determine ordering of processing, as
described by Noah's document (with modifications as indicated to
handle Glen's concern; this still relies on processing according to
the XML structure ordering).


> 3) It is allowed to introduce trailers after the body but only if a
> header points to them indicating that the trailer will follow and
> what it will contain (we don't define this). The SOAP/1.1 schema
> actually allows this but the description of how to deal with
> trailers is very vague.

Why is it necessary to point to them with a Module? If we're defining
a processing model for other blocks, it seems that it would cover
these as well; we'd just need to define constraints for their actor
(as discussed previously).



-- 
Mark Nottingham
http://www.mnot.net/

Received on Wednesday, 23 May 2001 17:36:09 UTC