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

Soap/WSDL typing question involving xsi:type

Expand Messages
  • rayjhax
    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
    Message 1 of 7 , Apr 14, 2003
    • 0 Attachment
      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
    • 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 2 of 7 , Apr 14, 2003
      • 0 Attachment
        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 3 of 7 , Apr 14, 2003
        • 0 Attachment
          --- 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 4 of 7 , Apr 14, 2003
          • 0 Attachment
            > 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 5 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 6 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 7 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.