SOAP Headers 4.8- intro paras

Here is my suggested change to 4.8 to mention that header and body needs to be
maintained synchronously.
I reordered the 2 roles, so that the scenario naturally  and directly follows
the role it represents.

I did leave out the thought: "desirable to use proprietary data formats or
techniques". In thinking about it, although true I didn't see that it was
relevant to i18n in particular or that headers were necessarily a solution for
proprietary formats.
I also thought that it is a mistake to appear to recommend that putting locale
in the header is a good idea, as opposed to associating context info in the
message itself alongside the data, was bad. I gave currency as an example.

So here it is- if I had more time I would create another scenario showing a
problem case, but I think the verbiage is adequate. 
hth
tex

4.8
The SOAP header is an optional element which can be used to extend SOAP
processing in an application-specific manner. The header specification is
intentionally minimal so that headers may be tailored to meet the needs of
various applications. 

SOAP headers may be used to initiate or control processing of the message data,
either by the ultimate receiver of the message or by intermediary nodes which
handle the message before it is routed to the ultimate receiver. In this role,
SOAP headers may contain information specifying the routing of SOAP messages
and the processing which may (or must) occur at intermediary nodes. 

Headers may be used to convey additional contextual information about data in
the body of the SOAP message. In the context of internationalization, although
applications are encouraged to use locale-neutral data formats, processes, and
methodologies, in locale-sensitive scenarios, the SOAP header can be used to
declare the locale to be associated with the SOAP message. Of course, this
technique can be extended to other culture-dependent information that is not
prescribed by the locale. (E.g. A SOAP message with shoe size data, might
require a SOAP header to declare the shoe measurement system that is used.)

Of course, generally, it is preferable to include contextual information
directly with the data. Currency is often given as an example of this, where it
is preferred to name the monetary unit with the amount. There is a risk when
contextual information is maintained separately from the data, (for example by
placing contextual information in a header) that modifications will be made to
one without appropriate changes to the other.

Another risk is that the message content references data from more than one
locale. This scenario will either not work (because the header is limited to
declaring one locale), or declaring multiple locales in a header will make for
a complex header-message relationship.

The following scenario shows a case where message encoding is changed and the
SOAP header prescribing the conversion is correctly removed once the conversion
is performed. A variation of this scenario that is a problem case, would be one
where the header remained after the conversion is performed, incorrectly
prescribing future conversions. It is easy to imagine scenarios where either
the header or the message is modified and the two are no longer properly
coordinated.

Received on Friday, 11 June 2004 00:45:26 UTC