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

RE: [soapbuilders] Soap/WSDL typing question involving xsi:type

Expand Messages
  • Wes Moulder
    Soapenc:Array is usually treated special. Since it s using the soap encoded rules, it doesn t quite follow normal schema processing. The thing to look at
    Message 1 of 7 , Apr 14, 2003
      Soapenc:Array is usually treated special. Since it's using the soap
      encoded rules, it doesn't quite follow normal schema processing. The
      thing to look at when processing arrays is to look at the arrayType
      attribute, if present.

      The reason I can see why people send "soapenc:Array" instead of
      "tns:ArrayOfString" is that some servers and clients key specifically
      off the type soapenc:Array, and don't traverse the hierarchy to find out
      if it descends from soapenc:Array. In other words, while it's probably
      wrong to define the type that way, it's more interoperable.

      Hope that helps explain it,
      --Wes

      -----Original Message-----
      From: rayjhax [mailto:ray@...]
      Sent: Monday, April 14, 2003 4:05 PM
      To: soapbuilders@yahoogroups.com
      Subject: [soapbuilders] Soap/WSDL typing question involving xsi:type

      After extensive discussion with schema experts, I believe that it is
      correct that if you have a known schema type and an explicit xsi:type
      in XML, the xsi:type should always be a subtype of the schema type.

      Otherwise, the schema has been violated, regardless of whether the
      actual value lives in the proper value space of the schema type,
      because specifying a type that is not a subtype violates the type rules.

      Unfortunately, Google services and a variety of tests made by people
      in the community do not follow this schema rule (among others).

      I frequently see the following:

      A complex type called foo:ArrayOfstring which derives from
      soap-enc:Array.

      This type is used in the WSDL to specify the type of, for example, a
      return value.

      But when I get the return value back from the service, it says
      xsi:type="soap-enc:Array" instead of xsi:type="foo:ArrayOfstring" and
      this breaks the contract of the schema which said it would be
      ArrayOfstring.

      By my interpretation, Google is wrong, as are a large number of tests,
      because this is an incorrect return.

      Does anyone have an alternative point of view on this case?

      Thanks,

      Ray Whitmer




      -----------------------------------------------------------------
      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/
    • rayjhax
      ... So we can t expect a processor which tries to do real schema validation based upon WSDL-specified types to work? We assume that senders and recipients are
      Message 2 of 7 , Apr 14, 2003
        --- In soapbuilders@yahoogroups.com, "Wes Moulder" <wes@t...> wrote:
        > Soapenc:Array is usually treated special. Since it's using the soap
        > encoded rules, it doesn't quite follow normal schema processing. The
        > thing to look at when processing arrays is to look at the arrayType
        > attribute, if present.
        >
        > The reason I can see why people send "soapenc:Array" instead of
        > "tns:ArrayOfString" is that some servers and clients key specifically
        > off the type soapenc:Array, and don't traverse the hierarchy to find out
        > if it descends from soapenc:Array. In other words, while it's probably
        > wrong to define the type that way, it's more interoperable.
        >
        > Hope that helps explain it,
        > --Wes

        So we can't expect a processor which tries to do real schema
        validation based upon WSDL-specified types to work? We assume that
        senders and recipients are not playing by real schema rules?

        It is less interoperable if people try to use schema rules which say
        that there is invalid XML being exchanged. In the long run, I
        generally think following the rules is more interoperable than not
        following them, at least to those who try to follow rules.

        Ray Whitmer
      • Rich Salz
        ... The WSDL encoding attribute means that the schema definitions cannot be used directly, but are understood to have additional processing. Short answer:
        Message 3 of 7 , Apr 14, 2003
          > So we can't expect a processor which tries to do real schema
          > validation based upon WSDL-specified types to work? We assume that
          > senders and recipients are not playing by real schema rules?

          The WSDL encoding attribute means that the schema "definitions" cannot be
          used directly, but are understood to have additional processing.

          Short answer: you can't do full schema validation on a WSDL file that
          uses SOAP RPC encoding.
          /r$
        • Pete Hendry
          You should have consulted soap-encoding experts ;) As Rich says in another mail, the schema can t be used directly for soap-encoding. In fact, it can be
          Message 4 of 7 , Apr 14, 2003
            You should have consulted soap-encoding experts ;)

            As Rich says in another mail, the schema can't be used directly for
            soap-encoding. In fact, it can be ignored altogether. soap-encoding is
            there to define the graph of an object value. The theory being that if
            you have an object instance you can serialize it to soap without any
            other information (apart from perhaps type mappings to use in
            arrayType). The schema is a description of roughly what this message
            will look like, but the soap section 5 and 7 rules actually govern what
            can go on the wire, and this is a lot more flexible than schema. So, you
            can define what you want in schema, but that is unfortunately not what
            you will get in many cases.

            A good example is the use of href/id. They are not generally described
            on types in the schema but soap-encoding is free to use them as it
            wishes. As soon as one href is used, the document cannot be validated by
            a standard parser since it can't follow the href.

            There is a general move towards the use of literal because of the more
            complex (more loosely defined) interop for soap-encoding (the number of
            ways one data graph can be written to XML being the main problem I
            think). You will find some stacks "do what they can" as far as
            validation for soap-encoding goes, but they have to be very flexible
            with what they receive.

            As far as you original mail describing what is returned by Google, it is
            valid according to SOAP1.1 (which doesn't deal with schema at all for
            soap-encoding) and most soap stacks would accept it.

            Pete


            rayjhax wrote:

            >After extensive discussion with schema experts, I believe that it is
            >correct that if you have a known schema type and an explicit xsi:type
            >in XML, the xsi:type should always be a subtype of the schema type.
            >
            >Otherwise, the schema has been violated, regardless of whether the
            >actual value lives in the proper value space of the schema type,
            >because specifying a type that is not a subtype violates the type rules.
            >
            >Unfortunately, Google services and a variety of tests made by people
            >in the community do not follow this schema rule (among others).
            >
            >I frequently see the following:
            >
            >A complex type called foo:ArrayOfstring which derives from soap-enc:Array.
            >
            >This type is used in the WSDL to specify the type of, for example, a
            >return value.
            >
            >But when I get the return value back from the service, it says
            >xsi:type="soap-enc:Array" instead of xsi:type="foo:ArrayOfstring" and
            >this breaks the contract of the schema which said it would be
            >ArrayOfstring.
            >
            >By my interpretation, Google is wrong, as are a large number of tests,
            >because this is an incorrect return.
            >
            >Does anyone have an alternative point of view on this case?
            >
            >Thanks,
            >
            >Ray Whitmer
            >
            >
            >
            >
            >-----------------------------------------------------------------
            >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/
            >
            >
            >
            >
          • Rich Salz
            ... I d quibble with the reason, but agree with the trend: SOAP RPC is being squeezed out of existence. The future is clearly SOAP wrapping around XML
            Message 5 of 7 , Apr 14, 2003
              > There is a general move towards the use of literal because of the more
              > complex (more loosely defined) interop for soap-encoding (the number of
              > ways one data graph can be written to XML being the main problem I
              > think). You will find some stacks "do what they can" as far as
              > validation for soap-encoding goes, but they have to be very flexible
              > with what they receive.

              I'd quibble with the reason, but agree with the trend: SOAP RPC is
              being squeezed out of existence. The future is clearly SOAP wrapping
              around XML sub-documents.
              /r$
            • soccercheng59
              Hi, All: You can refer to this link: http://lists.w3.org/Archives/Public/www-xml-schema- comments/2002JulSep/0114.html and you can find Ricky has already
              Message 6 of 7 , Dec 17, 2003
                Hi, All:

                You can refer to this link:
                "http://lists.w3.org/Archives/Public/www-xml-schema-
                comments/2002JulSep/0114.html"
                and you can find Ricky has already gave his comment on this problem
                since Sep. 2002,
                the following is his assumption:

                It seems to me that the problem can be solved if we ....
                1) Add a "typed reference" concept in XML-schema.
                2) Schema validation can traverse across the "href"

                but I think this is not enough,
                the following is my opinion:

                1)fundamental misusing(mismatch) between XML schema & SOAP encoding
                and WSDL.

                Ricky said in his article:
                "It seems to me there is a fundamental mismatch between XML schema
                and SOAP
                encoding. XML schema does have a very limited concept of reference
                (id/idref is typeless), complex object will mainly be embedded into
                another
                complex object. However, SOAP encoding almost use reference
                exclusively. Complex object will has a "href" into another complex
                object."

                You can see in the schema definition of soapenc at
                "http://schemas.xmlsoap.org/soap/encoding/"

                ....
                <xs:attribute name="root">
                <xs:annotation>....</xs:annotation>
                <xs:simpleType>
                <xs:restriction base="xs:boolean">
                <xs:pattern value="0|1" />
                </xs:restriction>
                </xs:simpleType>
                </xs:attribute>
                <xs:attributeGroup name="commonAttributes">
                <xs:annotation>....</xs:annotation>
                <xs:attribute name="id" type="xs:ID" />
                <xs:attribute name="href" type="xs:anyURI" />
                <xs:anyAttribute namespace="##other" processContents="lax" />
                </xs:attributeGroup>
                .....

                <!-- ----------------------------------------------------------->
                <xs:complexType name="byte">
                <xs:simpleContent>
                <xs:extension base="xs:byte">
                <xs:attributeGroup ref="tns:commonAttributes" />
                </xs:extension>
                </xs:simpleContent>
                </xs:complexType>
                <!-- ----------------------------------------------------------->
                ....

                in the schema segment above, soap encoding allows every type of
                soapenc to
                have "id" & "href" attributes,(but "root" is not allowed, I think
                this is a problem)

                the following is the SOAP Message and its schema definition in its
                WSDL for
                Amazon Web Services:

                <?xml version="1.0" encoding="UTF-8"?>
                <soapenv:Envelope
                xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"
                xmlns:xsd="http://www.w3.org/2001/XMLSchema"
                xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
                <soapenv:Body>
                <ns1:KeywordSearchRequest
                soapenv:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"
                xmlns:ns1="http://soap.amazon.com">
                <KeywordSearchRequest href="#id0"/>
                </ns1:KeywordSearchRequest>
                <multiRef id="id0" soapenc:root="0"
                soapenv:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"
                xsi:type="ns2:KeywordRequest"
                xmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/"
                xmlns:ns2="http://soap.amazon.com">
                <keyword>dog</keyword>
                <page>1</page>
                <mode>book</mode>
                <tag>webservices-30</tag>
                <type>lite</type>
                <devtag>your-dev-tag</devtag>
                </multiRef>
                </soapenv:Body>
                </soapenv:Envelope>

                <xsd:complexType name="KeywordRequest">
                <xsd:all>
                <xsd:element name="keyword" type="xsd:string"/>
                <xsd:element name="page" type="xsd:string"/>
                <xsd:element name="mode" type="xsd:string"/>
                <xsd:element name="tag" type="xsd:string"/>
                <xsd:element name="type" type="xsd:string"/>
                <xsd:element name="devtag" type="xsd:string"/>
                <xsd:element name="sort" type="xsd:string" minOccurs="0"/>
                <xsd:element name="locale" type="xsd:string" minOccurs="0"/>
                <xsd:element name="price" type="xsd:string" minOccurs="0"/>
                </xsd:all>
                </xsd:complexType>


                dispite of the "typed reference",
                for the validation of the "multiRef" element,
                we have to add "root", "id", href" attributts definition to its
                schema definition in WSDL. As shown below:

                <xsd:complexType name="KeywordRequest">
                <xsd:all>
                <xsd:element name="keyword" type="xsd:string"/>
                <xsd:element name="page" type="xsd:string"/>
                <xsd:element name="mode" type="xsd:string"/>
                <xsd:element name="tag" type="xsd:string"/>
                <xsd:element name="type" type="xsd:string"/>
                <xsd:element name="devtag" type="xsd:string"/>
                <xsd:element name="sort" type="xsd:string" minOccurs="0"/>
                <xsd:element name="locale" type="xsd:string" minOccurs="0"/>
                <xsd:element name="price" type="xsd:string" minOccurs="0"/>
                </xsd:all>
                <!-- --------------------------------------------------------------- -
                ->
                <xsd:attribute ref="soapenc:root"/>
                <xsd:attributeGroup ref="soapenc:commonAttributes"/>
                <!-- --------------------------------------------------------------- -
                ->
                </xsd:complexType>


                So I think for a SOAP Message to basically follows the use of schema,
                we better follows the extending rules in soapenc, that is to add
                "root", "id", href" attributts definition to its schema definition in
                WSDL.

                2) Just as Ricky said:
                1) Add a "typed reference" concept in XML-schema.
                2) Schema validation can traverse across the "href"



                I opinion is that SOAP & WSDL are "applications" of XML & Schema,
                hierarchically, SOAP & WSDL is on top of XML & Schema,
                so a Schema validator for SOAP Message has to be able to:
                (1) Inernally allow the "root", "id", "href" attribute for elements
                (2) handle the "typed reference" and "href" traversal

                I don't know if WS-I is discussing this problem or not,
                If anyone has more informations about this topic,
                please let me know

                THANX





                --- In soapbuilders@yahoogroups.com, Pete Hendry <peter.hendry@c...>
                wrote:
                > You should have consulted soap-encoding experts ;)
                >
                > As Rich says in another mail, the schema can't be used directly for
                > soap-encoding. In fact, it can be ignored altogether. soap-encoding
                is
                > there to define the graph of an object value. The theory being that
                if
                > you have an object instance you can serialize it to soap without
                any
                > other information (apart from perhaps type mappings to use in
                > arrayType). The schema is a description of roughly what this
                message
                > will look like, but the soap section 5 and 7 rules actually govern
                what
                > can go on the wire, and this is a lot more flexible than schema.
                So, you
                > can define what you want in schema, but that is unfortunately not
                what
                > you will get in many cases.
                >
                > A good example is the use of href/id. They are not generally
                described
                > on types in the schema but soap-encoding is free to use them as it
                > wishes. As soon as one href is used, the document cannot be
                validated by
                > a standard parser since it can't follow the href.
                >
                > There is a general move towards the use of literal because of the
                more
                > complex (more loosely defined) interop for soap-encoding (the
                number of
                > ways one data graph can be written to XML being the main problem I
                > think). You will find some stacks "do what they can" as far as
                > validation for soap-encoding goes, but they have to be very
                flexible
                > with what they receive.
                >
                > As far as you original mail describing what is returned by Google,
                it is
                > valid according to SOAP1.1 (which doesn't deal with schema at all
                for
                > soap-encoding) and most soap stacks would accept it.
                >
                > Pete
                >
                >
                > rayjhax wrote:
                >
                > >After extensive discussion with schema experts, I believe that it
                is
                > >correct that if you have a known schema type and an explicit
                xsi:type
                > >in XML, the xsi:type should always be a subtype of the schema type.
                > >
                > >Otherwise, the schema has been violated, regardless of whether the
                > >actual value lives in the proper value space of the schema type,
                > >because specifying a type that is not a subtype violates the type
                rules.
                > >
                > >Unfortunately, Google services and a variety of tests made by
                people
                > >in the community do not follow this schema rule (among others).
                > >
                > >I frequently see the following:
                > >
                > >A complex type called foo:ArrayOfstring which derives from soap-
                enc:Array.
                > >
                > >This type is used in the WSDL to specify the type of, for example,
                a
                > >return value.
                > >
                > >But when I get the return value back from the service, it says
                > >xsi:type="soap-enc:Array" instead of xsi:type="foo:ArrayOfstring"
                and
                > >this breaks the contract of the schema which said it would be
                > >ArrayOfstring.
                > >
                > >By my interpretation, Google is wrong, as are a large number of
                tests,
                > >because this is an incorrect return.
                > >
                > >Does anyone have an alternative point of view on this case?
                > >
                > >Thanks,
                > >
                > >Ray Whitmer
                > >
                > >
                > >
                > >
                > >-----------------------------------------------------------------
                > >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.