RE: SOAP Headers 4.8- intro paras

Thanks Tex. This is great text. I have incorporated it and uploaded the results.

Addison

Addison P. Phillips
Director, Globalization Architecture
webMethods | Delivering Global Business Visibility
http://www.webMethods.com
Chair, W3C Internationalization (I18N) Working Group
Chair, W3C-I18N-WG, Web Services Task Force
http://www.w3.org/International

Internationalization is an architecture. 
It is not a feature.

> -----Original Message-----
> From: Tex Texin [mailto:tex@xencraft.com]
> Sent: 2004年6月10日 21:45
> To: aphillips@webmethods.com
> Cc: I18n WSTF
> Subject: 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 10:39:01 UTC