Skill sets needed to consume web services is a frequent topic of conversation. I often hear from vendors and analyst that the consumer of a web services doesn't need to know anything about WSDL, SOAP or XML. I think many of them say that because a lot of the tools out there help abstract away that complexity from the consumer. For example in .Net when you consume a web service, the XML is marshaled and unmarshaled for you. The user ends up with a series of classes to work with instead of XML.
This is great assuming everything works correctly. The reality though is things don't always work correctly. More often than not, a developer with have to trace the messages being sent and returned from the web service. This means using something tcptrace to inspect the messages. Once the messages are being capture, comparing them to the WSDL is usually required. Understanding XML Schema, SOAP message structure and WSDL structure is required in order to do this. Things like namespace issues, type incompatibilities or improperly formatted SOAP messages are the usual suspects. But you have to know what you are looking at.
So does the developer need to be a XML expert? No, but a base level of skill is required. At a minimum, the developer should be able to read a WSDL and understand how to construct a proper SOAP message against it. The developer should also be able to tell when the SOAP message is constructed incorrectly. Without this minimum set of skills, developers will struggle to consume web services.