A web service I consume uses XSD to describe its API. Recently, they added a field to a reply message where no xsd:any had been, so when our schema validator tried to validate against the previous xsd, it failed. We considered this a backwards incompatibility and opened a ticket.Their architect replied that we should validate our outgoing messages (requests), but not bother to validate replies. We should pick and choose the fields we want in the replies and ignore the rest. He also said that we should set our schema validator to ignore new fields and validate the rest.If such a setting exists for some schema validators, then maybe this architect is not wrong, but on the other hand if my application breaks because a field I don't need to care about changed (or got created) doesn't that indicate a violation of the interface segregation principle? Is it really acceptable for me to validate the individual fields of the object piecemeal instead of expecting it to be all-or-nothing correct? I realize that not validating incoming data from an external service has security implications as well, but in this question I'm trying to learn about the architectural principles more than the security aspects.
Architecture: Should I schema validate incoming reply messages?
architecture;solid;schema
Their architect replied that we should validate our outgoing messages  (requests)...They are not practicing what they preach.  If they were, you'd be receiving messages valid to the XSD.The problem is definitely on their side and they should fix it, but in the real world we often have to work around issues others create, so you may need to not bother to validate replies just to keep things going.With Internet protocols in general, we try to generate standards compliant output while being tolerant of noncompliant input.  I'm trying to find the RFC about HTML or HTTP (or whatever it was) that put it this way, but not much luck at this time.  But the point is being tolerant on your side helps keep things going eventhough it feels dirty.