W3C home > Mailing lists > Public > xml-dist-app@w3.org > May 2001

Re: On the ordering of header entries

From: Mark Nottingham <mnot@mnot.net>
Date: Wed, 23 May 2001 14:36:04 -0700
To: Henrik Frystyk Nielsen <henrikn@microsoft.com>
Cc: Noah_Mendelsohn@lotus.com, Glen Daniels <gdaniels@macromedia.com>, XML dist app <xml-dist-app@w3c.org>, David Fallside <fallside@us.ibm.com>
Message-ID: <20010523143601.B4434@mnot.net>

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
Received on Wednesday, 23 May 2001 17:36:09 UTC

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