ilango,
Questions you should ask yourself about schema:

How strong is the interface contract?  Is there a distinction between interface definition and business process?  If the interface rules are distinct from the business process, how much of the interface contract that exists between the systems is expressible using XML schema?  Are there parts of the interface specification that cannot be conveniently expressed using schema?  If schema doesn't do all of it, how do you validate the rest of the interface contract, and how convenient is it?  Are there other technologies that are just as convenient (in development and deployment terms) as schema that are better at encoding the rules for the interface?  At bottom the question is, how well does the tool align with the business requirement?

There is an awful lot of schema experience out there, so it has an edge (in my part of the world anyway) on convenience, but it tends to lose out when looked at in terms of its ability to express business rules.  Most recently I did some review on an interface where the developers were trying to express a number of interface rules using schema (cross field validation expressed as choices among alternate complex types was a disturbing idea) but were not getting good coverage of their business rules with it.  I recommended a combination of a much simpler schema and schematron (and genericode) and some other stuff to get the focus back on the business rules and off the data structure.  They got where they got to by choosing a tool and then trying to make it do what they wanted instead of looking first at what they needed. 

Greg