WSDL without qualified namespace

[axel_johard]

Hi,
need some help with creating a WSDL file. I will try to summarize the
problem like this:

I need to create a wsdl that accepts a response that has no namespace-
prefix in the first line in the body, like this:
"...<soap:Body><UpdateCustomerDetailsResponse xmlns="AMI">..."

I have tried setting the schema-element like <s:schema
elementFormDefault="unqualified" targetNamespace="AMI"> and since this
is the "root" of the response, I can not see anothter place I can
change since the "root" element does not accept the form-attribute
when it is defined, for example like this: <s:element
name="UpdateCustomerDetailsResponse" form="unqualified"> (which
appears to be not accepted).

The strange thing is that this line <s:schema
elementFormDefault="unqualified" targetNamespace="AMI"> works with a
message that looks like
"...<soap:Body><AMI:UpdateCustomerDetailsResponse xmlns:AMI="AMI">..."
which to me seems to be contradictionary to how it is supposed to be
used.

I realize this is a complex problem to solve with just this
information but are there any common patterns or solutions to work
with when working with unqualified namespaces?

The problem appears in Biztalk when the message is received with the
error message: "The XLANG/s message has no part at index '0'. The
total number of parts found in the message is '0'. If you expect a
multipart message, check that the pipeline supports multipart messages
such as MIME.". I guess this is because no message is delivered to
Biztalk after the soap-adpater connection.

Thanks in advance!
Axel

 

[Tomas Restrepo [MVP]]

Hi Axel,

need some help with creating a WSDL file. I will try to summarize the
problem like this:

I need to create a wsdl that accepts a response that has no namespace-
prefix in the first line in the body, like this:
"...<soap:Body><UpdateCustomerDetailsResponse xmlns="AMI">..."

I have tried setting the schema-element like <s:schema
elementFormDefault="unqualified" targetNamespace="AMI"> and since this
is the "root" of the response, I can not see anothter place I can
change since the "root" element does not accept the form-attribute
when it is defined, for example like this: <s:element
name="UpdateCustomerDetailsResponse" form="unqualified"> (which
appears to be not accepted).

That's correct. XSD mandates that all root elements *must* be qualified if
the schema has a targetNamespace (form and elementFormDefault only apply to
non-root elements).

If I had to guess, I'd say you'd need to break your schema in two: One with
a targetNamespace that defines the inner elements, and one without a
targetNamespace that defines the <UpdateCustomerDetailsResponse/> root
element and imports the first schema.

 

[Axel]

Hi Tomas, thanks for a quick answer!

Actually, I have tried making the WSDL as I think you mean, one WSDL with
two schemas in it, but with no difference (still does not work).

I am guessing the top-tag "<wsdl:definitions..." which has a
targetNamespace="AMI" attribute also plays a part in this, but I don't think
I can remove that one since the targetnamespace is used at other places in
the WSDL.

I have also tried separating the response message to a separate WSDL but
with no luck, is that possible at all?

would appreciate some other suggestions...
Thanks/Axel

 

[Tomas Restrepo [MVP]]

Axel,

Hi Tomas, thanks for a quick answer!

Actually, I have tried making the WSDL as I think you mean, one WSDL with
two schemas in it, but with no difference (still does not work).

I was talking about separate schemas, not the WSDL (You can actually import
multiple external XSD files into a WSDL if you want, as well).

I am guessing the top-tag "<wsdl:definitions..." which has a
targetNamespace="AMI" attribute also plays a part in this, but I don't
think
I can remove that one since the targetnamespace is used at other places in
the WSDL.

Nope, that's the namespace for the definitions in the WSDL itself, not the
types in it (i.e. messages, portTypes, Services and so on). It doesn't
affect the namespaces used by the XML elements themselves at all.