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.