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

Interop Issue - Good Example

Expand Messages
  • W. Matthew Long
    I came across a good example of an interop issue. The WSDL at this url http://www.xmethods.net/sd/XMethodsListingsService.wsdl has schema associated with its
    Message 1 of 3 , Feb 5, 2001
    • 0 Attachment
      I came across a good example of an interop issue. The WSDL at this
      url
      http://www.xmethods.net/sd/XMethodsListingsService.wsdl
      has schema associated with its types element (this is included at the
      bottom). The schema is entirely correct, but does provide an
      interesting issue when returning or sending objects. This particular
      wsdl doc has an array of objects associated with it. Under
      a "normal" processor a part with type attribute = "xsd:ArrayOfFloat"
      can be easily resolved without the aid of schema. However, when the
      part has an element attribute the schema must be involved. In our
      implementation an element attribute is equivalent to passing an
      object, e.g., this is a critical issue (for us). In the example the
      response part's element attribute is "tns:ItemArray" . A processor
      could correctly determine that this object is an array of objects by
      retrieving the preappended the "Array" from the text and prefixing
      with non-"xsd". However, it would appear more gentle to
      use "tns:ArrayOfSOAPService" as this would be as easily resolvable
      into
      a) element attribute confirms schema is involved (object in our case)
      b) "tns" confirms same as [a]
      c) "ArrayOf" signals and array is present (which is same when xsd
      type is present.
      d) "SOAPService" gives us the root of the schema tree to resolve
      downward.

      Opinions.....?????

      -Matt
      ..........the schema........
      <types>
      <schema
      targetNamespace="http://www.xmethods.net/XMethodsListingService.xsd"
      xmlns="http://www.w3.org/1999/XMLSchema">
      <element name="SOAPService">
      <complexType>
      <sequence>
      <element name="name" type="string"/>
      <element name="owner" type="string"/>
      <element name="description" type="string"/>
      <element name="homepageURL" type="string"/>
      <element name="endpoint" type="string"/>
      <element name="SOAPAction" type="string"/>
      <element name="methodNamespaceURI" type="string"/>
      <element name="methodName" type="string"/>
      <element name="wsdlURL" type="string"/>
      <element name="instructions" type="string"/>
      <element name="contact_email" type="string"/>
      <element name="serverImplementation" type="string"/>
      </sequence>
      </complexType>
      </element>
      <element name="itemArray">
      <complexType name="ArrayOfSOAPService" base="soap:Array">
      <all>
      <element name="item" type="xsdl:SOAPService"/>
      </all>
      </complexType>
      </element>
      </schema>
      </types>
    • Simon Fell
      ... Assuming xsd points to http://www.w3.org/1999/XMLSchema then xsd:ArrayOfFloat doesn t exist. what i ve seen everyone else do for arrays, is to define their
      Message 2 of 3 , Feb 5, 2001
      • 0 Attachment
        On Tue, 06 Feb 2001 00:15:41 -0000, in soap you wrote:

        >I came across a good example of an interop issue. The WSDL at this
        >url
        >http://www.xmethods.net/sd/XMethodsListingsService.wsdl
        >has schema associated with its types element (this is included at the
        >bottom). The schema is entirely correct, but does provide an
        >interesting issue when returning or sending objects. This particular
        >wsdl doc has an array of objects associated with it. Under
        >a "normal" processor a part with type attribute = "xsd:ArrayOfFloat"
        >can be easily resolved without the aid of schema.

        Assuming xsd points to http://www.w3.org/1999/XMLSchema then
        xsd:ArrayOfFloat doesn't exist. what i've seen everyone else do for
        arrays, is to define their own type for arrays, following the
        recommended naming convention from the WSDL spec. (there's still an
        outstanding debate of how exactly the array should be defined)

        This could be massively simplified by someone coming up with a schema
        that defines all the common array types and importing it in. However
        the current MS toolkit doesn't support import, and i'm not sure how
        many others do.

        >However, when the
        >part has an element attribute the schema must be involved. In our
        >implementation an element attribute is equivalent to passing an
        >object, e.g., this is a critical issue (for us). In the example the
        >response part's element attribute is "tns:ItemArray" . A processor
        >could correctly determine that this object is an array of objects by
        >retrieving the preappended the "Array" from the text and prefixing
        >with non-"xsd". However, it would appear more gentle to
        >use "tns:ArrayOfSOAPService" as this would be as easily resolvable
        >into
        >a) element attribute confirms schema is involved (object in our case)
        >b) "tns" confirms same as [a]
        >c) "ArrayOf" signals and array is present (which is same when xsd
        >type is present.
        >d) "SOAPService" gives us the root of the schema tree to resolve
        >downward.
        >
        >Opinions.....?????

        ok, try this.

        1. complex types can be "linked" from the messages section to the
        types section via a element name / element pair or a complex type /
        type pair

        2. the uri for tns needs to match the targetnamespace in the
        \\types\schema section

        3. the complex type definition is inheriting from soap:Array and this
        should be used to indicate that its an array. the all/sequence/element
        info within the complexType has the info to de-reference the array
        contents.

        (IMO) basing it on the text name is a mistake, you've got to pick your
        way through all the schema references, I'm beginning to understand why
        Jacek didn't like it !

        Cheers
        Simon
        www.pocketsoap.com
      • Tony Hong
        Regarding Matt s suggestion, I may be misunderstanding... but If you use tns:ArrayOfSOAPService directly, wouldn t you need to use
        Message 3 of 3 , Feb 6, 2001
        • 0 Attachment
          Regarding Matt's suggestion, I may be misunderstanding... but
           
          If you use "tns:ArrayOfSOAPService" directly, wouldn't you need to use
           
          type="tns:ArrayOfSOAPService"
           
          in the part definition rather than using the element attribute? Since
           
          tns:ArrayOfSOAPService
           
          is a reference directly to a complexType definition?
           
          Perhaps one rule could be:
           
          If the message part is referencing an element, then you do your object construction
          after you've determined the type, either by looking at a <complexType> child of the
          element or by following a "type" attribute on the element.
           
          Then, you end up at "ArrayOfSOAPService" and go from there, and Simon's rule #3
          kicks in.
           
          Or am I completely off base here?
           
          Thanks,
          Tony
           
           
           
           
           
          -----Original Message-----
          From: Simon Fell [mailto:soap@...]
          Sent: Monday, February 05, 2001 5:24 PM
          To: soapbuilders@yahoogroups.com
          Cc: wsdl@yahoogroups.com
          Subject: [wsdl] Re: [soapbuilders] Interop Issue - Good Example

          On Tue, 06 Feb 2001 00:15:41 -0000, in soap you wrote:

          >I came across a good example of an interop issue.  The WSDL at this
          >url
          >http://www.xmethods.net/sd/XMethodsListingsService.wsdl
          >has schema associated with its types element (this is included at the
          >bottom).  The schema is entirely correct, but does provide an
          >interesting issue when returning or sending objects.  This particular
          >wsdl doc has an array of objects associated with it.  Under
          >a "normal" processor a part with type attribute = "xsd:ArrayOfFloat"
          >can be easily resolved without the aid of schema. 

          Assuming xsd points to http://www.w3.org/1999/XMLSchema then
          xsd:ArrayOfFloat doesn't exist. what i've seen everyone else do for
          arrays, is to define their own type for arrays, following the
          recommended naming convention from the WSDL spec. (there's still an
          outstanding debate of how exactly the array should be defined)

          This could be massively simplified by someone coming up with a schema
          that defines all the common array types and importing it in. However
          the current MS toolkit doesn't support import, and i'm not sure how
          many others do.

          >However, when the
          >part has an element attribute the schema must be involved.  In our
          >implementation an element attribute is equivalent to passing an
          >object, e.g., this is a critical issue (for us).  In the example the
          >response part's element attribute is "tns:ItemArray" .  A processor
          >could correctly determine that this object is an array of objects by
          >retrieving the preappended the "Array" from the text and prefixing
          >with non-"xsd".   However, it would appear more gentle to
          >use "tns:ArrayOfSOAPService" as this would be as easily resolvable
          >into
          >a) element attribute confirms schema is involved (object in our case)
          >b) "tns" confirms same as [a]
          >c) "ArrayOf" signals and array is present (which is same when xsd
          >type is present.
          >d) "SOAPService" gives us the root of the schema tree to resolve
          >downward.
          >
          >Opinions.....?????

          ok, try this.

          1. complex types can be "linked" from the messages section to the
          types section via a element name / element pair or a complex type /
          type pair

          2. the uri for tns needs to match the targetnamespace in the
          \\types\schema section

          3. the complex type definition is inheriting from soap:Array and this
          should be used to indicate that its an array. the all/sequence/element
          info within the complexType has the info to de-reference the array
          contents.

          (IMO) basing it on the text name is a mistake, you've got to pick your
          way through all the schema references, I'm beginning to understand why
          Jacek didn't like it !

          Cheers
          Simon
          www.pocketsoap.com


          To unsubscribe from this group, send an email to:
          wsdl-unsubscribe@yahoogroups.com


        Your message has been successfully submitted and would be delivered to recipients shortly.