So I jumped into a discussion on microsoft.public.dotnet.framework.webservices where the author asked the best way to send DataSets over web services. One of the initial responses was basically (to paraphrase) “...just pass it as strings and use GetXml, ReadXml to dehydrate/rehydrate the DataSet...”. The author of said post has, IMHO, been trying to tap dance out of that statement, but he only seems to be digging himself deeper. Anway, I leave the reading of that thread up to you if you're interested.
The real reason for this post is the ever increasing scenario where I see people recommending passing strings of XML around. The worst case, IMO, is in the web services (SOAP) space. You're playing in a world of pure XML here. You have full control over strong typing of your web method messages using XML Schema, so why would you choose to hide your glorious XML inside of a string? How are clients supposed to discover what they're supposed to send to you if you've basically designed your web service like a C++ method that takes void*? Would you design your .NET APIs to take all strings? Why not? That's essentially what you're doing when you take this approach with your web services.
Ok, so the truth is not that many people are passing strings around in .NET web services, but what they are passing around is DataSets. Basically passing a DataSet around results in the following XML Schema message type being generated for your web service using the default/built-in WSDL generator invoked by the ?wsdl querystring to your web service:
<s:sequence>
<s:elementminOccurs="0"maxOccurs="1" name="test">
<s:complexType>
<s:sequence>
<s:elementref="s:schema"/>
<s:any/>
</s:sequence>
</s:complexType>
</s:element>
</s:sequence>
Literally that translates to: “Pass me an XML schema followed by any well-formed XML element.”. This is light years more structured than the string approach at least, but still doesn't provide any insight to consumers as to what you expect in terms of data. Remember, your consumers are not only going to be using .NET (that's the whole idea!). They may not have an class that understands this pattern. In fact, the only reason wsdl.exe proxy generation for a web method with the afforementioned signature even translates to a DataSet is because it's basically a well known pattern that it's hardcoded to detect. There's no proof that's actually a .NET DataSet on the other end of the wire. It just so happens that as long as you have a schema followed by a xsd:any, DataSet would be a damn good candidate for parsing it.
That's why I always say to people who want to go this route: “Sure, feel free to use a DataSet in your .NET signature, just make sure to define your WSDL contract and message schemas by hand.”. WSDL first! :)