Jonathan Altman

Earlier, I posted about how not forcing all access to web services to go through objects that were serialized into and back out of XML but instead were XML documents that were designed to stand on their own made it easier to implement both web services and web services clients.

Elliotte Rusty Harold sets out a nice short example of the nature of the problem. He summarizes the problem nicely in this quote

"don't "help" users out by changing XML into something else, especially not objects. Don't assume you know what they're going to want to do with the data. Give them the XML and let them use the classes and objects that fit their needs, not the ones that fit your needs. XML is exchangeable. Objects are not."

Again, for the record: if I work with your web service, you do not know what data, data structures, or code artifacts I will have in place to access your web service. Please don't try to guess by forcing me through your view of how the software artifacts should look. Let me figure out how to make the raw message, and how to interpret what you send back. SOAP toolkits that closely map XML to particular language-specific data structure constructs and back make this hard.