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

Re: [soapbuilders] Interop Issue - Good Example

Expand Messages
  • 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 1 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 2 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.