Web Services Interoperability - .NET & Java

For those who are attempting to write web services in .NET to be consumed in Java.
The following are things to note or watch out for:

1. Note the WS-I guideline found here
2. Run the WS-I tests first to ensure that the web services comply with Basic Profile 1.0. Download the "Interoperability Testing Tools 1.1" from here
3. Refrain from having the same name for operation and parameter type (this causes Axis 1.4 to fail as it attempts to generate classes for service and parameter type. Axis will try to generate the same class for both. For example: a complex type named search will "clash" with an operation with the same name. In the WSDL: <s:complexType name="search"> will "clash" with <s:operation name="search">)
4. Refrain from incorporating non-ASCII characters directly into the content of a string property (which finally gets serialized into XML). Use character encoding instead. E.g., do not use “smart quotes” directly; use &#8220; and &#8221;
5. If you expect the returned content to be transformed by XSLT (common in content publishing), consider returning the content as xs:string. E.g. use string getDocument(...) instead of Document getDocument(...).

Point (5) requires further explanation. The rationale is that most developers will make use of the framework proxy generator (wsdl2Java or wsdl.exe) in Java or even .NET to generate proxy classes. Most proxy generator will automatically convert the return type (if it isn't string) to schema-based data classes. As such getDocument(...) : Document will cause the Document class to be generated.
At runtime when the web service is called, an instance of the Document class will be returned to the caller of the operation. Behind the scenes, the XML gets deserialized into the Document object.
In order to have the original XML, the Document has to be serialized back into the XML. A total waste of computation!