The response section defines the responses returned by default by each operation. The following snippet shows some of the specifications of an ItemSearch response.

<xs:element name="ItemSearchResponse">
  <xs:complexType>
    <xs:sequence>
    <xs:element ref="tns:OperationRequest" minOccurs="0" />
    <xs:element ref="tns:Items" minOccurs="0" maxOccurs="unbounded" /> 
    </xs:sequence>
  </xs:complexType>
</xs:element>

The response section shows that an ItemSearch response contains two optional (minOccurs=0) elements, OperationRequest and Items. Both of these elements are references (ref=), which means that they are defined further down in the WSDL.

Further down in the WSDL, OperationRequest is defined, as follows.

<xs:element name="OperationRequest">
  <xs:complexType>
    <xs:sequence>
      <xs:element ref="tns:HTTPHeaders" minOccurs="0" /> 
      <xs:element name="RequestId" type="xs:string" minOccurs="0" /> 
      <xs:element ref="tns:Arguments" minOccurs="0" /> 
      <xs:element ref="tns:Errors" minOccurs="0" /> 
      <xs:element name="RequestProcessingTime" type="xs:float" minOccurs="0" maxOccurs="1" /> 
    </xs:sequence>
  </xs:complexType>
</xs:element>

This definition also contains several references. One is Arguments, which is defined further down in the WSDL. To fully understand the definition of the parts of a request, you keep digging down through the layers of refs. You know that you have reached the end of the definition hierarchy when you no longer have "ref" in the element's definition. Instead, the element definition will have a "name," the name of the element, and "type," which specifies the element's type. The type will be a base type, such as, string, which is defined in the schema (xs:), as shown.

<xs:element name="RequestId" type="xs:string" minOccurs="0" />

This line defines RequestId to be of type string, which is defined by the W3C schema.

When you look at a sample response, shown in the following example, you can see how the definition of RequestId is carried out.

<ItemSearchResponse xmlns="
http://ecs.amazonaws.com/AWSECommerceService/2006-09-13">
...
  <OperationRequest>
  ...
    <RequestId>0VFY0HFBRTJGRE6KES74</RequestId>

First, you see that the value for RequestId is string. Secondly, the name of the element is RequestId. Third, you can see, in the XML hierarchy, how the definition of RequestId is nested inside the OperationRequest element, which is nested inside of ItermSearchResponse. Remember, it was the "ref" keyword that created the nesting in the WSDL.