Hints for various WS-I problems:
--------------------------------

1) For the WSI failure with assertion WSI2102, check to see if you are
importing the soap encoding definitions.  Since only rpc/literal and
document/literal are permitted, these definitions are not needed.
Remove lines like:

	<import namespace="http://schemas.xmlsoap.org/soap/encoding/"/>

2) Clearly, do NOT define types in terms of soap-encoded types.  This
will likely show up as violations of WSI2417.

3) All wsdlsoap:fault elements must have the name attribute
specified.  Use the name of the enclosing wsdl:fault element.  This
will show up as problems WSI2703, WSI2022 and WSI2032.

4) All faults must be defined in terms of XML schema elements.  Change
type attributes to element attributes in wsdl:message elements.
Define an element in terms of the exception type.  This fixes WSI2113.

5) Define arrays in terms of elements with minOccurs and maxOccurs
attributes specified.  This fixes WSI2108.

Recommendations:
----------------

1) Supply a name attribute on the wsdl:definitions element.  This is
used by the WSDLDoc generator.  If not supplied WSDLDoc will use the
unhelpful name 'NoName' which may also then be overwritten by the
content of other unnamed wsdl files. 

2) For document/literal WSDL specifications name the XML schema
element referenced by an operation (through a message element) the
same as the operation itself.  This is the only requirement of
document/wrapped which isn't enforced by the WS-I requirements.
Note that document/wrapped is a valid document/literal definition. 

3) Faults must reference an element in the XML schema because it is
treated as a "literal" component.  However do define a type hierarchy
of faults so that these can be mapped more naturally into exceptions
for the languages which support them.  I.e., 

         <xs:complexType name="GenericFault">
           <xs:sequence>
              <xs:element name="message" type="xs:string"/>
              <xs:element name="detail" type="xs:string"/>
           </xs:sequence>
         </xs:complexType>

         <xs:complexType name="UnknownSchemaFaultType">
           <xs:complexContent>
              <xs:extension base="tns:GenericFault">
                 <xs:sequence>
                    <xs:element name="message" type="xs:string"/>
                    <xs:element name="detail" type="xs:string"/>
                 </xs:sequence>
              </xs:extension>
           </xs:complexContent>
         </xs:complexType>

         <xs:element name="UnknownSchemaFaultElement" 
                     type="common-types:UnknownSchemaFault"/>

Remember to specify at least one new extension element or to repeat
all of the existing elements, otherwise the type will be empty (and
gSoap will complain). 

Limitations from Python bindings:
---------------------------------

1) Do NOT define anonymous simpleContent enumerations.  Instead define
explicit simpleTypes.  I.e. do NOT do:

    <complexType name="QueryProperties">
        <sequence>
            <element name="type">
                <complexType>
                    <simpleContent>
                        <restriction base="xsd:string">
                            <enumeration value="latest"/>
                            <enumeration value="continuous"/>
                            <enumeration value="history"/>
                            <enumeration value="static"/>
                        </restriction>
                    </simpleContent>
                </complexType>
            </element>
            <element name="timeInterval" type="xsd:int" minOccurs="0"/>
        </sequence>
    </complexType>

But instead define an explicit type:

    <simpleType name="QueryEnumeration">
        <restriction base="xsd:string">
            <enumeration value="latest"/>
            <enumeration value="continuous"/>
            <enumeration value="history"/>
            <enumeration value="static"/>
        </restriction>
    </simpleType>

    <complexType name="QueryProperties">
        <sequence>
            <element name="type" type="rgma:QueryEnumeration"/>
            <element name="timeInterval" type="xsd:int" minOccurs="0"/>
        </sequence>
    </complexType>

This is also cleaner and simplier to understand. 

2) The targetNamespace attribute must appear on all xsd:schema
elements.  Leaving this off causes a "Key error: 'targetNamespace'"
when using SOAPpy. 

3) The targetNamespace of an enclosing xsd:schema element must be
different than the namespace attribute on any xsd:import element.
SOAPpy does not allow the redefinition of types within a namespace
that are imported.  This restriction also appears in .NET.  

Limitations from gSoap:
-----------------------

1) All XML schema definitions in a single namespace MUST be declared
withing a single xsd:schema element when using document/literal
encoding.  If definitions are split between different xsd:schema
elements, then gsoap will generate warnings about not being able to
find the various elements.

2) Empty messages in document/literal must be written as 

         <xs:element name="SetACLResponse">
           <xs:complexType/>
         </xs:element>

otherwise gSoap will complain that it cannot find the given type.