Dan, the V1 .net client proxy generator assumed the wrong default for
schema/@elementFormDefault. I believe you can get the client to send the
correct messages by editing the schema and explicitly setting
schema/@elementFormDefault="true" and regenerating the proxy. Our V1.1
(which is currently available as a beta) addresses this issue.
From: danweston53 <dweston@...
Sent: Friday, December 20, 2002 9:21 AM
Subject: [soapbuilders] .NET, doc-literal, and qualified local elements
When .NET generates client code from a doc-literal WSDL, that code
expects that all elements and sub-elements in the request and response
messages belong to the target namespace of the schema, even if the
schema says otherwise (i.e. schema uses elementFormDefault =
unqualified). This is in disagreement with the client code generated by
the Axis 1.1 toolkit. Who is right?
I've written a really simple web service in Java with a hand-rolled WSDL
file  that specifies document-literal semantics for the messages. I
then used the WSDL to generate client code with Axis and .NET, but the
clients don't agree on what the messages should look like. I thought
doc-literal was supposed to make interop a no-brainer. Maybe someone on
this list can see what is going on here.
The schema for the request message, taken from the WSDL, looks like
<xsd:element name="d1" type="xsd:double"/>
<xsd:element name="d2" type="xsd:double"/>
<!-- response omitted for brevity -->
If I use a wsdl containing that schema to generate client code with Axis
1.1, it sends the following request message, which is what I would
Note that d1 and d2 elements are in NO namespace, which is what I expect
from the schema (assuming that the default value of elementFormDefault
If I use Visual Studio .NET to generate client code from the same WSDL,
I get the following request message...
Note here that the d1 and d2 elements in the DEFAULT namespace,
urn:com-develop-ejws:SimpleMaths, which is not what I expect, so the
Xpath I use in my web service servlet doesn't work.
Given the schema, I don't believe that the sub-elements d1 and d2 should
belong to the target namespace, but should be in no namespace. It
appears to me that .NET is imposing its own ideas about namespaces on my
message schema and ignoring what my schema really says.
Several possibilities present themselves:
1. there could be something wrong with my WSDL, although Axis is able to
generate the client code that I expect.
2. The .NET client code is wrong, Axis is right.
3. The Axis code is wrong, .NET is right
4. I guess I could fix this by changing my schema to use
elementFormDefault = qualified so that Axis and .NET would generate the
same messages, but that feels like I am giving in to MS.
Could some of you wizards take a look at my WSDL and see what you think?
Feel free to generate client code and bang on the service (although it
is running on my laptop and there is no guarantee that it will always be
up and running...)
This group is a forum for builders of SOAP implementations to discuss
implementation and interoperability issues. Please stay on-topic.
To unsubscribe from this group, send an email to:
Your use of Yahoo! Groups is subject to