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

Re: [soapbuilders] WSDL parsers -- what's really done

Expand Messages
  • Pete Hendry
    ... Restriction is a tough one! How is restriction modelled in an OO language (more specifically Java)? Extension is easy as it is a standard OO concept. A
    Message 1 of 3 , Jul 17, 2001
    • 0 Attachment
      > Here the focus has been on basics, element decl's, simple and
      > complex types, common particles(e.g. <all>, <sequence>) and
      > indeed Restriction. Section 5 arrays, for instance, are all derived
      > from SOAP-ENC:Array by restriction.
      >

      Restriction is a tough one! How is restriction modelled in an OO language (more specifically Java)? Extension is easy as
      it is a standard OO concept. A extends B so B can be used where A is expected. This is true in schemas as well.

      With restriction, if A restricts B then it is not true to say B can be used where A is expected (in Java). A may require
      more information (elements) than B so an instance of B may not be an instance of A (lost yet?).

      Example

      <complexType name="A">
      <restriction base="tns:B">
      <sequence>
      <element name="m" type="xsd:string"/>
      </sequence>
      </restriction>
      </complexType>

      <complexType name="B">
      <sequence>
      <element name="m" type="xsd:string"/>
      <element name="n" type="xsd:string"/>
      </sequence>
      </complexType>

      <complexType name="C">
      <extension base="tns:B">
      <sequence>
      <element name="p" type="xsd:string"/>
      </sequence>
      </extension>
      </complexType>

      Now if I have a method

      public void method( B arg );

      and the variables

      A a;
      B b;
      C c;

      then in Java it is valid to say

      method( b );
      method( c );

      but not valid to say

      method( a );

      because A does not 'extend' B but restricts it. In fact you could turn it around and say that A restricts B => B extends
      A and so the method

      public void method( A arg );

      could potentially take

      method( a );
      method( b );

      and, by association

      method( c );

      even though C has not direct relation to A. Working this kind of thing out for code gen is a nightmare!

      This is not so simple in java as it would either require multiple inheritance or knowing in advance all the types that
      restrict another complex type so a scheme of using interfaces could be drawn up in advance.

      To be honest, the whole concept of having restriction of a complexType is lost on me. Because you have to repeat all the
      elements and attributes you want to keep from the original you are effectively defining a new type. I would have
      preferred to have restriction for simpleTypes to allow adding facets but not have it for complexTypes. The life of the
      person writing a code generator would then have been much easier.

      Don't get me started on substitutionGroups and their implications for code generation!!

      > Anyone requiring comprehensive Schema processing capability
      > certainly has their work cut out for them if they want to roll their
      > own implementation!
      >

      I couldn't agree more on this point. It is a shame that the Schema spec has made things so complex. In my opinion it
      should have stuck to standard OO type definitions and not tried to overcomplicate things as it has. Large parts of the
      schema spec could be dropped with only minor impact on its power (if any).

      Pete
    Your message has been successfully submitted and would be delivered to recipients shortly.