Nope, this isn't what XSD is designed to accomplish. If you're trying to define what the object looks like from a data perspective in XSD, it's not related to any other object. So, each one can only be describe atomically.
The only way I could think to do that in XSD is if the that has Y, is and always is the FIRST in your list of items, then it could be done. You could design the element to have 2 nodes as allowed children. You define the first as something like "ItemYesType" and it is required and there can be only 1. Then you have a "ItemNoType" which is optional and 0 to many in cardinality. Then you've basically got 2 separate schema objects, one that requries "Y" and one that requires "N".
The other way to validate this type of message is with XSLT. You can very easily write a transformation to check for this constraint. If it fails the constraint, you throw an error and stop the message with and error. We do in our house for complicated business rules that XSD cannot validate (Exactly like yours). We put a message through XSD Validation, then we push it into an XSLT constraint check immediately after.