Comments on Web Services Internationalization Usage Scenarios -- W3C Working Draft 20 December 2002

Please find below some comments about the 20 December 2002 draft of
Web Services Internationalization Usage Scenarios[1].

| 2.1.1.2 Description
| 
|    SOAP is used for XML messages exchanging data among service nodes.

Nitpicking: "service nodes" implies that two services are talking
together while SOAP only talks about nodes (sender and receiver) that
could be anything. I would replace "service nodes" by "nodes" or
"communicating parties", or something equivalent which would be more
neutral.

| 2.1.2.2 Description
| 
|    This scenario is divided into three aspects.
|     1. A sender sends a SOAP message in non-Unicode encoding.
|     2. A receiver receives a SOAP message in non-Unicode encoding.
|     3. Interaction between SOAP layer and SOAP interface such as  
|        programming language, middleware, operating systems etc. 

I was (and still am) a bit confused about this scenario which talks
about a SOAP layer and a SOAP interface. The concepts SOAP layer and
SOAP interface do not appear in SOAP Version 1.2 Part 1: Messaging
Framework[2], however, the XML Protocol Abstract Model[3] does show 3
layers[4]:
- the underlying protocol layer.
- the XMLP layer.
- the XMLP application.

Interestingly, the Web Services Architecture document[5] is not
extremely explicit about this and the XML Protocol Abstract Model
should be harvested to reflect this. I am putting this on my to-do
list.

Anyway, back to I18N issues, I think that the problem of character
encoding manifests itself at two levels:
- between the underlying protocol layer and the XMLP layer. A SOAP
  binding takes care of the bridging from one to the other. The
  binding has the responsibility of reconstructing the infoset, and
  the underlying protocol of the receiver could not support the
  encoding used by the sender.
- between the XMLP layer and the XMLP application: the application
  could, as mentioned in section 2.1.2.2, not support a particular
  encoding.

| 2.2.1.2 Description
|      
|    When a SOAP fault occurs, SOAP fault messages containing natural
|    language descriptions of the error(s) are sent back to the requester.
|    The requester usually wants to see error messages in the requester's 
|    preferred language(s) and data format. Currently the following
|    mechanism is available with the HTTP binding.
|     
|    Accept-language: The Accept-Language request-header field restricts
|    the set of natural languages that are preferred as a response to the
|    request. [RFC2616]
|    
|    Using Accept-language, a requester can notify a provider of the  
|    requester's language preference. A provider can then send SOAP-Fault
|    messages in the requester's preferred language(s). If a SOAP message 
|    does not use the HTTP binding, how can a SOAP-Fault message detect
|    the requester's language preference.

Some I18N problems may indeed be solved with Accept- headers, but
these are indeed specific to HTTP.

Conveniently, SOAP 1.2 defines the concept of feature[6] which are
some properties and extensions of a SOAP message that can be expressed
either in the envelope or in the binding.

One could imagine a I18N extension describing I18N-specific
processing. When possible, e.g. with HTTP, some of these properties
could be carried by the underlying protocol, and when not, they could
still be present in the SOAP envelope.

Such meta-data is part of what people have called policies (encoding
and language preference and requirements, security features, privacy
policy, etc) in the context of Web services, which IMO applies to more
than only Web services. The Web Services Description Working Group has
a task force working on describing these properties and features in
WSDL 1.2, and their role and place in the architecture is not well
known yet.

| 2.2.8 Language Preference for Multiple Transmission Protocols Binding
|                                                                      
| 2.2.8.1 Scenario Definition                                          
|                             
|    SOAP message variation if http or ftp or SMTP or RMI or IIOP
|    (difficulty deploying in a single WSDL)
|    
| 2.2.8.2 Description
| 
|     1. Service "A" is defined on Provider "A".
|     2. The administrator of Provider "A" wishes to deploy the same   
|        service on several bindings simultaneously in the same WSDL file.
|        
|      * SOAP structure requires different semantics for language
|        preference for each binding?                            

This is where features could help.

| 2.3.4 Locale Dependent Datatypes
| 
| 2.3.4.1 Scenario Definition
| 
|    A sender wishes to send locale dependent data to a receiver for
|    regional SOAP messaging or RPC. The receiver needs to process the
|    locale dependent data correctly.
|    
| 2.3.4.2 Description
[..]
|    If WSDL can describe locale sensitive datatypes, locale negotiation
|    mechanism can be described in WSDL. Is it applicable requirement for
|    interface definition of WSDL?   

WSDL's feature description support might be the key for this IMO.

| 2.5.1 Locale Sensitive Processing by Provider(Receiver)
| 
| 2.5.1.1 Scenario Definition
| 
|    The service provider needs the locale of the sender in order to
|    perform locale sensitive processing. There are three levels to this:
|    Transport layer, service provider layer (SOAP Header), and service
|    layer (SOAP Body) (we need separate scenarios for these)
|
| 2.5.1.2 Description
[..]

As I mentioned above, SOAP 1.2 does not talk about layers. I do not
understand the distinction made between SOAP headers and body. Since
they are part of the same infoset, it seems to me that they suffer
from the same problems. Maybe when there are additional scenarios as
hinted in this section, things will become clearer.

Nonetheless, I would be careful about introducing this concept of two
layers in a SOAP message which I think isn't present in the SOAP 1.2
specification.

Regards,

Hugo

  1. http://www.w3.org/TR/2002/WD-ws-i18n-scenarios-20021220/
  2. http://www.w3.org/TR/2002/CR-soap12-part1-20021219/
  3. http://www.w3.org/TR/2001/WD-xmlp-am-20010709/
  4. http://www.w3.org/TR/2001/WD-xmlp-am-20010709/#Sec2
  5. http://www.w3.org/TR/2002/WD-ws-arch-20021114/
  6. http://www.w3.org/TR/2002/CR-soap12-part1-20021219/#soapfeature
-- 
Hugo Haas - W3C
mailto:hugo@w3.org - http://www.w3.org/People/Hugo/

Received on Tuesday, 25 March 2003 09:21:10 UTC