>My Web Service always returns data in XML string. From the client side, this requires the client to manipulate that XML string in order to get the data in the way it is desired. From VFP, this can be accomplished by using XMLTOCURSOR(). But, outside of that environment, the client would have to DOM into the XML string and get the piece of data that is required for the display or any other kind of needs.
>
>Knowing that the Web Service is done in .NET and that the client who would access some specific methods would also be .NET, would that be the best way to simply return a DataSet?

Yes that's generally a good approach. Although no other clients will understand the data set directly (SOAP Toolkit for instance) you can always get the XML and parse it manually if you need to. For example in VFP you can return the dataset parse it out of the SOAP message then use the XMLAdapter to turn it back to cursors and vice versa. It's pretty painless and about 4 or 5 more lines than it would be to get the data returned as a string.

The problem comes on the other end. There's no way that I know of to send a DataSet to a .Net Web Service and have it recognize it as a DataSet using the SOAP toolkit unless you hand code the SOAP packets. The reason is that the DataSet is treated like an object and doesn't encode the XML, which if you pass a string with the SOAP toolkit will not be the case. I've done this with wwSOAP by using a special direct SOAP mapping, but this is also more work.

So that leaves you with a consistency issue <g>... no easy choices here.

Basically if your primary audience is .Net work wiuth datasets directly - otherwise use XML strings. Another alternative is to implement dual methods -one for the dataset one for XML strings. Use a consistent post fix for each and you can make both happy. THe string methods can simply perform some conversion and otherwise defer all the business work to the DataSet methods.

+++ Rick ---


>
>I would like some feedback on both approaches in regards to the pros and cons.