More feedback from my earlier post…
ChadBr came up with the best reason I have heard so far on when you might return XML encoded as a string instead of the actual XML from a Web service.
What if you don’t want the overhead of creating the DOM on the server in the 1st place?
I agree that one of the downfalls of the current .NET Web service implementation is that it kind of shoe horns you into using the DOM to deal with XML when you might prefer to use an XmlReader/Writer or some other XML api. So an advantage of passing XML as a string is that you can load the string into an XmlReader and avoid the overhead of loading up an instance of a DOM. This idea has some merit in my mind, not a ton, but some.
But let me also say that most of the cases where I’ve seen XML returned as a string, the first thing that is done with the string is it is loaded into a DOM instance–so obviously no DOM overhead is being saved.
Later in the comment Chad wrote:
If I want to process the data from a database before it’s sent back to the client, I probably want to process it in the form of a dataset or datareader — neither returns a DOM –
Let’s make something REALLY, REALLY, REALLY, REALLY, REALLY, REALLY, REALLY, REALLY clear. Take advantage of the XML serialization that automatically happens. Generally you do not want to take objects, convert them into DOM instances, then return the DOM instances from your Web methods instead of the objects. You can return the objects themselves and for most cases the .NET Framework does the right thing and builds appropriate XML. More importantly, for a typical object (typical meaning most things that aren’t Datasets), you will get a nice schema defined in your WSDL for your object’s XML serialization that will allow consumers of your Web service to better understand the data you are sending/receiving. Datasets are a little funny in the way they do serialization, but you can return a Dataset from a Web method and a .NET client can pick it up as a Dataset on the other side. You don’t have to turn it into XML first to send it. And you certainly don’t have to turn it into XML and then into a string to send it.
And just in case you missed Mike’s post about MS CRM, you can find it here. This falls into the category of tool limitations during design and appropriate repenting after the fact with promises that he shall sin no more. Like I said before, I’ve been there so I have a lot of sympathy.