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

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

Expand Messages
  • 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 1 of 7 , Apr 14, 2003
    • 0 Attachment
      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 2 of 7 , Apr 14, 2003
      • 0 Attachment
        > 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 3 of 7 , Dec 17, 2003
        • 0 Attachment
          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.