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

RE: [soapbuilders] problem with schema for encoded arrays in interoptest.wsdl

Expand Messages
  • Kirill Gavrylyuk
    Hi, Bob! Thank you for reply, I absolutely understand and sympathize the goals behind this change. But... ... Yes, MS SOAP Toolkit and ASP.Net DO NOT accept a
    Message 1 of 6 , Nov 9, 2001
      Hi, Bob!
      Thank you for reply, I absolutely understand and sympathize the goals behind this change. But...

      >Does this actually break any real world WSDL processors?
      Yes, MS SOAP Toolkit and ASP.Net DO NOT accept a schema you used for arrays in interoptest.wsdl. We accept and generate the one from the WSDL 1.1 example:
      <complexType name="ArrayOfstring">
      <complexContent>
      <restriction base="SOAP-ENC:Array">
      <attribute ref="SOAP-ENC:arrayType" wsdl:arrayType="string[]"/>
      </restriction>
      </complexContent>
      </complexType>

      >If it's ok to have one SOAP encoding attribute declared in the schema, how can having others (such as SOAP-ENC:offset) really cause interop problems?
      I think partially it is caused by WSDL sec 2.2 rules you pointed out. Partially it is caused by interpreting WSDL encoded array example as abstract array type definition and following this example.

      I totally agree with you that sec 2.2 is ambiguous, and WSDL 1.1 spec needs to be rewritten and these ambiguities should be clarified.

      The point I'm trying to make is that:
      1) Attempt to change the encoded array schema to be XSD 2001 compatible doesn't give any benefits, arguable (at least) from WSDL1.1 spec point of view, and breaks interop at least with some WSDL processors. Why don't we wait till new rewritten WSDL spec comes out?

      2) It is hard to come up with the 2001 schema that would describe every possible way of encoded array's serialization allowed by Section 5. I don't think your schema allows href/ids or different names for array element children for example. So why bother changing the schema at all at least before new WSDL spec is issued?

      What do you and others think?

      >Anyway, the concern I have is... Will reverting to the previous (arguably incorrect, from an XS pov) schema cause interoperability problems as well? Whose tools would break using a schema like that in the WSDL 1.1 example?
      I hope nobody's, since everybody seem to interop with ASP.Net and SOAP Toolkit generated WSDLs. But thank you for raising this - definetly needs to be answered before we revert.

      Thanks a lot.

      -----Original Message-----
      From: Bob Cunnings [mailto:cunnings@...]
      Sent: Friday, November 09, 2001 8:26 PM
      To: soapbuilders@yahoogroups.com
      Subject: Re: [soapbuilders] problem with schema for encoded arrays in
      interoptest.wsdl


      Hi Kirill,

      Hmmm.

      Absolutely, this needs to get straightened out in the next version of WSDL.

      Originally the schema for the array types used for the interop tests was just like the example in WSDL 1.1, but several objections were raised. The schema was felt to be incorrect, the most often cited reference given was the CapeConnect FAQ [1]. A schema for an array derived from SOAP-ENC:Array, using the 2001 schema, is found in the SOAP 1.2 draft [2], and was used as a model.

      So the interop schema was updated in response to this.

      What's unclear is the actual impact on interoperability... shouldn't it be rather benign? Most toolkits appear to deal with the updated schema without any trouble. Does this actually break any real world WSDL processors? It would be a funny thing, if the schema is intrinsically correct. What's odd (upon reflection) is that WSDL sec 2.2 [3] attempts to impose its own rules on the content of schemas placed in the <types> container.

      My question is partly unanswered... If it's ok to have one SOAP encoding attribute declared in the schema, how can having others (such as SOAP-ENC:offset) really cause interop problems? It could be argued that the third bullet ("Array types should extend the...") in the rules list in WSDL sec 2.2 creates a contradiction that can only be resolved by considering the rule given in the second bullet ("Don't include attributes or elements...")to be overruled. In other words, once you've allowed one, how could having any more make any difference?

      Anyway, the concern I have is... Will reverting to the previous (arguably incorrect, from an XS pov) schema cause interoperability problems as well? Whose tools would break using a schema like that in the WSDL 1.1 example?

      As I stated earlier, there is no reason why the schema can't be reverted to the old form if that's the consensus.
      FWIW, the WSDL processor here can handle either case, so I don't care personally.

      What say the rest of you?

      RC

      [1] http://www.capescience.com/library/articles/common-wsdl-errors.html#_Toc520090303
      [2] http://www.w3.org/TR/2001/WD-soap12-part2-20011002/#arrays
      [3] http://www.w3.org/TR/wsdl#_types

      > >lets hope this is nailed once and for all when WSDL is updated for SOAP 1.2
      >
      > +1. My only hope as well.
      >
      > To answer the Bob's question - I think the reason why WSDL 1.1 spec added this attribute was to put a wsdl:arrayType on it. And that's the only information tools look for when they parse encoded array's schema in wsdl.
      >
      > So for the sake of interop we propose to stick to the the same array declaration from WSDL 1.1 until WSDL spec gets updated through the standards process.
      >
      > Does everybody concur?
      >
      > Current version of Toolkit and .Net use array declaration from WSDL 1.1 - is this the one others use?
      >
      > Thanks.
      >
      >
      > -----Original Message-----
      > From: Simon Fell [mailto:soap@...]
      > Sent: Friday, November 09, 2001 3:40 PM
      > To: soapbuilders@yahoogroups.com
      > Subject: Re: [soapbuilders] problem with schema for encoded arrays in
      > interoptest.wsdl
      >
      >
      > That's exactly what sprung into my mind as well !
      >
      > arrays in WSDL have always been problematic, lets hope this is nailed
      > once and for all when WSDL is updated for SOAP 1.2
      >
      > Cheers
      > Simon
      >
      > On Fri, 9 Nov 2001 16:30:51 -0700, in soap you wrote:
      >
      > >Hello,
      > >
      > >This could certainly be done, but I have a question:
      > >
      > >Doesn't the inclusion of the attribute decl for the SOAP-
      > >ENC:arrayType in the example violate the very rule you cite? It is
      > >certainly an attribute peculiar to the encoding, right?
      > >
      > >How is it that it may be included in the schema, yet the other
      > >attribute declarations may not?
      > >
      > >My point is that the WSDL spec may be contradicting itself in
      > >Section 2.2.
      > >
      > >RC
      > >
      > >> Hi, all!
      > >> We recently noticed that schema for arrays in InteropTest.wsdl [1] and InteropTestB.wsdl [2] got changed, now they use the following:
      > >> <complexType name="ArrayOfstring">
      > >> <complexContent>
      > >> <restriction base="SOAP-ENC:Array">
      > >> <sequence>
      > >> <element name="item" type="string" minOccurs="0" maxOccurs="unbounded" nillable="true"/>
      > >> </sequence>
      > >> <attributeGroup ref="SOAP-ENC:commonAttributes"/>
      > >> <attribute ref="SOAP-ENC:offset"/>
      > >> <attribute ref="SOAP-ENC:arrayType" wsdl:arrayType="string[]"/>
      > >> </restriction>
      > >> </complexContent>
      > >> </complexType>
      > >>
      > >> Can we change them back to match an example in WSDL 1.1 spec [3]? Here is what I think matches the previous schema and the WSDL 1.1 spec most closely:
      > >>
      > >> <complexType name="ArrayOfstring">
      > >> <complexContent>
      > >> <restriction base="SOAP-ENC:Array">
      > >> <attribute ref="SOAP-ENC:arrayType" wsdl:arrayType="string[]"/>
      > >> </restriction>
      > >> </complexContent>
      > >> </complexType>
      > >> ?
      > >>
      > >> As I understood the reason for a change is to try to adopt the schema for XSD2001 requirements on derivation by restriction and to repeat the base type content explicitly. That is a good goal.
      > >>
      > >> But I believe that there was a subtle error introduced, namely that the earlier schema did not declare extra attributes and the proposed new schema declares some.
      > >>
      > >> 1. Looking through the wsdl spec, section 2.2 makes me believe that soap-enc:offset, soapenc:commonAttributes group and other attributes MAY NOT be used in the schema section of WSDL:
      > >> * Don't include attributes or elements that are peculiar to the wire encoding (e.g. have nothing to do with the abstract content of the message). Some examples are soap:root, soap:encodingStyle, xmi:id, xmi:name.
      > >> 2. These attributes are not needed. SOAP encoding rules treat the schema as a struct definition, not as the direct basis for validation. What is needed is only the elements in the struct or array and the attribute declaration for wsd:arrayType.
      > >>
      > >> We have a better chance of Interop if we change the schema as little as possible from the original WSDL1.1 spec. I believe we should use the same array declaration from WSDL 1.1 spec.
      > >>
      > >> What do others think?
      > >>
      > >> [1] http://www.whitemesa.com/interop/InteropTest.wsdl
      > >> [2] http://www.whitemesa.com/interop/InteropTestB.wsdl
      > >> [3] http://www.w3.org/TR/wsdl
      > >>
      > >>
      > >>
      > >>
      > >>
      > >> -----------------------------------------------------------------
      > >> 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/
      > >>
      > >
      > >
      > >
      > >-----------------------------------------------------------------
      > >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/
      > >
      >
      >
      >
      > -----------------------------------------------------------------
      > 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/
      >
      >
      >
      > -----------------------------------------------------------------
      > 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/
      >
      >



      -----------------------------------------------------------------
      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.