RE: Issue 263 Response

This is not a WG response but a comment from me as an individual member
of the XML Protocol WG (for a WG response, see [1] by David Fallside).

While I am glad to see your positive response [2] to David's statement,
the purpose of this mail is to provide some background and clarification
of the resolution provided by the XML Protocol WG. I hope this may be of
assistance in evaluating the concerns you raise.

The concerns 1) and 2) seem to imply that the intent of the resolution
provided is to have a sender generate a reason text in all languages
supported by the sender. However, as you point out in 3), and with which
I agree, this makes little sense as there is no guarantee that there is
any overlap between the sender's and the receiver's natural language and
obvious performance problems as a result of doing so. The purpose of the
resolution is therefore merely to *enable* the support for indicating
multiple natural languages in a SOAP fault.

What I don't agree with is jumping to the conclusion that the core SOAP
messaging framework should provide a specific language negotiation
mechanism. I think there are several reasons for keeping things separate
in this regard:

A) It is not clear to me that one would want a dedicated natural
language negotiation mechanism for SOAP faults and not for other parts
of the message, or even for other parameters, i18n or otherwise, to be
declared or negotiated. For example, HTTP provides negotiation for not
only natural language but for a variety of parameters such as character
set, media type, and content encoding, only some of which are i18n
related. Defining a negotiation mechanism is, as you know, not a small
undertaking: It would require gathering requirements, usage scenarios
(maybe similar to those you have already begun listing), and determining
how it may relate to existing mechanisms. By itself this task is out of
scope of what the XML Protocol WG is chartered to do.

B) I don't see any requirement for a negotiation mechanism to be
embedded within the SOAP messaging framework. In fact, it would seem
useful to have the general negotiation mechanism be separate so that it
may be applicable in other contexts too. For example, the negotiation
mechanism defined in HTTP based on accept* header fields is also used in
other protocols like SIP and RTSP. Similarly, an XML-based negotiation
mechanism may be applicable in a wider context.

C) The very point of negotiation is that there is a bidirectional
communication like for example a request followed by a response. While
SOAP supports such kinds of interactions, it also supports one-way
messages and other message exchange patterns that may potentially
include more than two parties. It is not clear that the same negotiation
mechanism will apply in these scenarios.

Regarding a few specific comments:

> - A general recommendation that each Web service provide a language
> negotiation mechanism and that this mechanism be used in providing 
> human readable natural language text, such as SOAPFault reasontext 
> attributes.

I absolute agree making a general recommendation for how to consider
i18n related issues--this makes a lot of sense. In fact, one could argue
that this would be better stated as an architectural principle rather
than as part of the SOAP specification. Given the reasons above,
however, I would be weary having SOAP provide or recommend any
particular solution in this space as I can see multiple potentially
applicable solutions.

> - A specific "Accept-Language" SOAP header along the lines of RFC3066 
> (which defines the HTTP Accept-Language header)

Note that the "accept-language" HTTP request header field and its role
in the HTTP content negotiation mechanism is defined by HTTP and not RFC
3066. RFC 3066 defines an identifier mechanism and a registration
mechanism for possible values of this header field.

> - An "International Context" SOAP header that provides extensible 
> support for other i18n-related information

Before doing so, I think it should at least be evaluated whether it
would make sense to have such a mechanism be isolated to i18n-related
information or whether it should apply to other areas as well.

>We also have the following comments:
>
>1. Specifically state that the first env:Text entry should be 
>considered the "default" text, to be used when no match is obtained by 
>the requestor with languages in the list. This ensures that the human 
>reader always has some text available.

In my opinion this is entirely an implementation/configuration issue of
the receiver. In general, there is no requirement that there be a human
directly associated with either a SOAP sender or a SOAP receiver, nor
that any particular parts of a SOAP message be exposed to a human.

Given the above, I personally believe the XML Protocol WG made pretty
much the right trade off when considering support for multiple natural
languages in a SOAP fault reason.

Thank you,

Henrik Frystyk Nielsen
mailto:henrikn@microsoft.com

[1] http://lists.w3.org/Archives/Public/xmlp-comments/2002Dec/0019.html
[2] http://lists.w3.org/Archives/Public/xmlp-comments/2002Dec/0020.html

Received on Thursday, 12 December 2002 15:34:15 UTC