W3C home > Mailing lists > Public > www-ws@w3.org > February 2004

Re: WSDL definitions / targetNamespace

From: Anne Thomas Manes <anne@manes.net>
Date: Mon, 09 Feb 2004 10:05:59 -0500
Message-Id: <>
To: "Rob Henley" <rob.henley@freeuk.com>, <www-ws@w3.org>


The targetNamespace in the <wsdl:definitions>  element creates a namespace 
for all the elements that you define in the WSDL document (messages, 
portTypes, bindings, services, and ports). Although the attribute is 
optional, you should always create a namespace. The WS-I Basic Profile 
makes this a required attribute.

The targetNamespace in the <xsd:schema> elements in the types section 
creates a namespace for all the elements that you define in the schema 
(elements, attributes, complexTypes, etc). This namespace may be the same 
as the WSDL targetNamespace or it may be different. If you have plans to 
use the schema definition in multiple services, it makes sense to create 
different namespaces. If the schema definition will only be used by the one 
Web service, then it makes sense to use just one namespace.

The <wsdl:definitions> targetNamespace does not in any way restrict imports 
of other WSDL files. In fact, if you plan to import other WSDL files, its 
more important to create a targetNamespace to allow you to distinguish 
between the imported WSDL elements and those created in the WSDL file. When 
you import a WSDL file, you also import that file's namespace -- which 
should be different from the targetNamespace.

When using RPC style services, the SOAP runtime generates the RPC wrapper 
element (the child element of the <soap:Body>). It derives the element's 
local name from the operation name, and the namespace from the namespace 
attribute on the <soap:body> definition. For example:

This binding definition:

<wsdl:operation name="foo">
     <soap:body use="literal" namespace="urn:foo-namespace" />

Would produce:

     <m:foo xmlns:m="urn:foo-namespace">

The WSDL 1.1 and SOAP 1.1 specs don't specify what namespace the child 
elements (the parameters) of the RPC wrapper element belong to. (These 
elements are also generated by the SOAP runtime and aren't defined by any 
schema.) The WS-I Basic Profile specifies that these elements should not be 
namespace qualified -- they are local elements to the RPC wrapper element. 
The child elements of these parameter elements are defined by a schema (in 
the <types> section), so these elements belong to the namespace defined in 
the <schema> targetNamespace.

If these is no targetNamespace defined on the <xsd:schema> element, then 
the defined schema elements belong to no namespace. Likewise, if there is 
no targetNamespace defined on the <wsdl:definitions> element, then the 
defined wsdl elements beling to no namespace.

As a best practice, you should always define a targetNamespace.


At 03:55 AM 2/9/2004, Rob Henley wrote:
>Can anyone help me understand the use of the (optional) targetNamespace on 
>the WSDL 1.1 defintions tag?
>The value can clearly be different from any targetNamespace(s) on schema 
>elements in the types section., but is often the same in simple examples.
>One use for the targetNamespace at the defintions level seems to be to 
>restrict imports of other WSDL files (they must all have the same 
>targetNamespace). Other issues which occur to me are:
>- if I'm using rpc style then the outer level tag of a SOAP request is 
>derived from the WSDL operation name (i.e. it isn't defined in Schema). Do 
>these outer tags in the SOAP instance document belong to the namespace 
>defined at the WSDL defintions level? (With their child elements 
>potentially belonging to other namespaces as specified on WSDL schema 
>- if there is no targetNamespace attribute on a WSDL schema element, does 
>it default to the target namespace of the defintions element?
>- if there is no targetNamespace on the WSDL defintions element?
>Many thanks!

Anne Thomas Manes
VP & Research Director
Burton Group 
Received on Monday, 9 February 2004 10:34:55 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 23:05:14 UTC