Re: Issue 4: Use of namespace attribute on soap:body

 Gudge,
 when use='encoded', the namespace attribute is a parameter to 
the encoding used (indicated by encodingStyle). When style='rpc', 
the namespace attribute is the namespace of the rpc wrapper 
element.
 Therefore the namespace attribute is significant when 
use='encoded' OR style='rpc'. It's only insignificant when 
both use='literal' AND style='document'.
 So the clarification sought could be:

 The use='literal' means the elements in schema will be in the
target namespace of that schema; use='encoded' means the encoding
governs the namespace, usually taking the value of the namespace
attribute.
 Analogically, style='document' means the elements in Body will
be in the target namespace of the appropriate schema; style='rpc'
means the (wrapper) element in Body will be in the namespace
indicated by the namespace attribute.

                   Jacek Kopecky

                   Senior Architect, Systinet Corporation
                   http://www.systinet.com/



On Tue, 25 Jun 2002, Martin Gudgin wrote:

 > 
 > I took an AI at the last telcon to write up Issue 4. Here is that write
 > up.
 > 
 > The issue is about interaction between the namespace attribute on
 > soap:body and the targetNamespace of global element declarations in a
 > schema.
 > 
 > The namespace attribute on the soap:body binding extension element is
 > only applicable when use='encoded' where it defines the namespace
 > qualification of the 'wrapper' element for the RPC parameters. The local
 > name of the wrapper element is defined by the name property of the input
 > / output pieces of a portType operation. When use='encoded' the parts
 > attribute of soap:body refers to parts defined using type='' rather than
 > element=''. Therefore the interaction does not exist.
 > 
 > Spo I'm not sure there is much of an issue here. We might want to
 > clarify that if use='literal' then the namespace attribute on soap:body
 > is not applicable.
 > 
 > Gudge
 >

Received on Thursday, 4 July 2002 19:39:48 UTC