The answer to quiz 4 is quite surprising:

<s:complexType name="AddRequestMsg">

     <s:sequence>

     <s:element minOccurs="1" maxOccurs="1" name="a" type="s:int" />

     <s:element minOccurs="1" maxOccurs="1" name="b" type="s:int" />

     </s:sequence>

</s:complexType>

And this, although the CLR type obviously tells the XML-serializer to generate attributes instead of elements:

public class AddRequestMsg

{

   [XmlAttribute]

   public int a;

   [XmlAttribute]

   public int b;

}

Note, this is not a bug, it’s a feature: The described Web Method uses the section 5 encoding style by applying the [SoapRpcMethod] attribute. Well, by definition, this encoding doesn’t support attributes. Therefore XML elements get generated although [XmlAttribute] has been specified.

Removing the [SoapRpcMethod] and we get the expected schema:

<s:complexType name="AddRequestMsg">

   <s:attribute name="a" type="s:int" use="required" />

   <s:attribute name="b" type="s:int" use="required" />

</s:complexType>

Now thinking the other way round: What happens if a section 5 encoding Web Service refers to a XML schema that contains XML attributes?

Answer: It’s simply not valid.