Loading ...
Sorry, an error occurred while loading the content.

.NET, doc-literal, and qualified local elements

Expand Messages
  • danweston53 <dweston@nerdworks.com>
    Abstract: 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
    Message 1 of 2 , Dec 20, 2002
    • 0 Attachment
      Abstract:

      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?

      Details:

      I've written a really simple web service in Java with a hand-rolled
      WSDL file [1] 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
      this:

      <types>
      <xsd:schema xmlns:xsd='http://www.w3.org/2001/XMLSchema'
      xmlns:tns='urn:com-develop-ejws:SimpleMaths'
      targetNamespace='urn:com-develop-ejws:SimpleMaths'>

      <xsd:complexType name="AddRequestType">
      <xsd:sequence>
      <xsd:element name="d1" type="xsd:double"/>
      <xsd:element name="d2" type="xsd:double"/>
      </xsd:sequence>
      </xsd:complexType>
      <xsd:element name="AddRequestMessage"
      type="tns:AddRequestType"/>

      <!-- response omitted for brevity -->
      </xsd:schema>
      </types>

      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 expect...

      <soapenv:Body>
      <AddRequestMessage xmlns="urn:com-develop-ejws:SimpleMaths">
      <d1 xmlns="">33.2</d1>
      <d2 xmlns="">88.33</d2>
      </AddRequestMessage>
      </soapenv:Body>

      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 is 'unqualified').

      If I use Visual Studio .NET to generate client code from the same
      WSDL, I get the following request message...

      <soap:Body>
      <AddRequestMessage xmlns="urn:com-develop-ejws:SimpleMaths">
      <d1>22.3</d1>
      <d2>44.2</d2>
      </AddRequestMessage>
      </soap:Body>

      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...)

      [1]http://slowtrain.placo.com:9080/OrinocoService/
      SimpleMathsServlet?wsdl

      Thanks,

      Dan Weston
    • Alex DeJarnatt
      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
      Message 2 of 2 , Dec 20, 2002
      • 0 Attachment
        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.
        Thanks
        alex

        -----Original Message-----
        From: danweston53 <dweston@...> [mailto:dweston@...]

        Sent: Friday, December 20, 2002 9:21 AM
        To: soapbuilders@yahoogroups.com
        Subject: [soapbuilders] .NET, doc-literal, and qualified local elements


        Abstract:

        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?

        Details:

        I've written a really simple web service in Java with a hand-rolled WSDL
        file [1] 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
        this:

        <types>
        <xsd:schema xmlns:xsd='http://www.w3.org/2001/XMLSchema'
        xmlns:tns='urn:com-develop-ejws:SimpleMaths'
        targetNamespace='urn:com-develop-ejws:SimpleMaths'>

        <xsd:complexType name="AddRequestType">
        <xsd:sequence>
        <xsd:element name="d1" type="xsd:double"/>
        <xsd:element name="d2" type="xsd:double"/>
        </xsd:sequence>
        </xsd:complexType>
        <xsd:element name="AddRequestMessage"
        type="tns:AddRequestType"/>

        <!-- response omitted for brevity -->
        </xsd:schema>
        </types>

        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
        expect...

        <soapenv:Body>
        <AddRequestMessage xmlns="urn:com-develop-ejws:SimpleMaths">
        <d1 xmlns="">33.2</d1>
        <d2 xmlns="">88.33</d2>
        </AddRequestMessage>
        </soapenv:Body>

        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
        is 'unqualified').

        If I use Visual Studio .NET to generate client code from the same WSDL,
        I get the following request message...

        <soap:Body>
        <AddRequestMessage xmlns="urn:com-develop-ejws:SimpleMaths">
        <d1>22.3</d1>
        <d2>44.2</d2>
        </AddRequestMessage>
        </soap:Body>

        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...)

        [1]http://slowtrain.placo.com:9080/OrinocoService/
        SimpleMathsServlet?wsdl

        Thanks,

        Dan Weston



        -----------------------------------------------------------------
        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:
        soapbuilders-unsubscribe@yahoogroups.com



        Your use of Yahoo! Groups is subject to
        http://docs.yahoo.com/info/terms/
      Your message has been successfully submitted and would be delivered to recipients shortly.