Web services that take and return XML documents - why?

Question

Are there benefits of writing a web service interface whose methods all take and return XML documents, rather than the more usual parameter lists of native types and classes?

We have some existing web services that are designed like this. The XML documents that are passed to their methods are typically large (as in they contain maybe 100 pieces of data that are relevant to the method calls). We have XSD files that we use to validate the XML documents, but the overall client developer experience is poor and slow. Surely it would be preferable to have a strongly-typed interface?

The web services are written in C#, and the clients are written in C# and also Java (some of our business partners use Java).

Answer 1

If you absolutely know for sure what your end-user/client technology is (for example pure .NET and Java where the feature set is probably the richest) then by all means go ahead and take advantage of strongly typed interfaces where available. But if your client base is a mixed bag of Perl, PHP, ASP, Python etc, then I'd keep life simple and accessible for these folks.

We have a number of web services that have to be consumable by this sort of mixed bag of clients, and whilst I'd love to make life simple for us, we have to dumb down a bit purely to ensure maximum interoperability.

Answer 2

Another reason would be certain very complicated XML documents that could be represented as classes, but which would be awkward. Deeply nested documents with many repeating elements, for instance: doc.a[3].b.c[4].d[52].e, for instance, gets tiresome very quickly.

Additionally, keep in mind that not all XML schema constructs can translate directly to classes. They're not meant to. An XML Schema that was built to be XML and not types may very well not translate into classes at all.