With all the talk going on I agree that this is bad:
[WebService]
public class MyWebService
{
[WebMethod]
public string GetSomeXML()
{
// get some xml
return xml;
}
}
And:
public class MyClient
{
public static void Main()
{
MyWebService objWS = new MyWebService();
string strXML = objWS.GetSomeXML();
XmlDocument doc = new XmlDocument();
doc.LoadXml(strXml);
// processing
}
}
A lot better (in most situations) is:
[WebService]
public class MyWebService
{
[WebMethod]
public XmlDocument GetSomeXML()
{
// return xml
}
}
The former scenario serializes the document directly into the output SOAP stream, therefore bypassing double string (de)serialization.
There are special cases, when one would like to bypass the other approach (passing XML as XmlDocument) on the server side. If you have all the data ready and want to pass it as quickly as humanly possible, without rehydrating the entire full blown DOM-capable object, you would use System.String (xsd:string in the XML world) and System.Text.StringBuilder to contacenate it.
If you don't know what to choose I propose this:
- It is year 2004, therefore platform and tool support is available in a way that XML processing is not a limitation from the XSD type system -> platform type system conversion side. Therefore choose XmlDocument.
- Choose XmlDocument.
- Choose the string way if and only if you are expecting clients which have no other way to bridge/decouple the raw SOAP XML string into something programmatic inside your platform.
In any case, things will change in late July or early August.