Рассмотрим сценарий десериализации. У вас есть набор XML, который читает DataContractSerializer. Представьте, что вы имеете дело с типом Foo, который помечен как IsReference = true и IsRequired = true.
Сериализатор обнаруживает поле foo1 типа Foo. Теперь это означает, что XML может сказать что-то вроде следующего:
<foo1 ref="1" /?
Сериализатор десериализует foo1 в null, но помните, что он ссылался на объект, которого у него еще нет. Сериализатор продолжает десериализацию оставшихся полей. В конце концов, он сталкивается с другим полем, как показано ниже. Ага, он видит объект, на который foo1 ссылался ранее - объект с идентификатором 1.
<foo2 id="1"> <datamember1> ... </datamember1> <datamember2> ... </datamember2> </foo2>
Когда встречается id = "1", сериализатор возвращается и исправляет foo1, указывая на foo2.
Однако, foo2 может никогда не существовать. Другими словами, foo1 может ссылаться на идентификатор, который не существует нигде в XML. У сериализатора нет возможности узнать это наверняка, пока он полностью не десериализовал остальную часть графика.
Надеюсь, вы начнете видеть проблему. Если тип был и IsReference, и IsReequired, то сериализация больше не может гарантировать , что природа типа IsRequired будет соблюдаться во время десериализации. Он больше не может быстро потерпеть неудачу, если требуемый элемент не существует, потому что он не может быть уверен, существует ли он.