> Just to clarify:
> Per the SOAP spec definition of the <detail> element , the <detail>
> element contains detail entries. A detail entry is a child element of the
> <detail> element, and it is identified by its qname. Therefore,
> <detail><ns1:part2 xsi:type="xsd:string">White Mesa
> is correct and
> <detail xsi:type="xsd:string">White Mesa Test</detail>
> is incorrect.
>  http://www.w3.org/TR/SOAP/#_Toc478383507
> (although I question why the type information is included in the message)
> The format of the <ns:part2> element should be defined as a message <part>
> in WSDL using document style (the <part> definition must specify an
> attribute rather than a type attribute).
Hmmm, not necessarily, IMO. Many of the tests in question  specify SOAP
encoded fault details, for example in the binding "SimpleRpcEncBinding" we
find "SimpleFault1" described as:
And in these cases the message that the fault ultimately maps to looks
something like this:
<part name="part2" type="xsd:string"/>
Since SOAP encoding is in use the message part must specify a type. From
WSDL 1.1 sec. 3.5  :
"If use is encoded, then each message part references an abstract type using
the type attribute."
SOAP encoded fault details are permitted by SOAP 1.1 and may be described
using WSDL 1.1, as evidenced by the definition of the soap:fault binding
As is so often the case with WSDL 1.1, navigation between the (supposedly
orthogonal) rpc/document "style" and encoded/literal "use" dichotomies in
WSDL 1.1 can be treacherous.