В предыдущей статье "Как избежать запутанности" (Avoiding Complexity) из серии "Принципы проектирования XML-схем" автор объяснил

:

"Правила определения сложных типов посредством наложения ограничений описаны в Разделах

и

Рекомендации W3C "XML Schema". Большинство багов в реализациях тесно связаны с этой функциональностью, и довольно часто при обсуждении различных нюансов получения таких производных типов разработчики высказывают самое серьезное недовольство. Более того, этот способ определения производных типов не полностью соответствует понятиям ни предметно-ориентированного программирования, ни теории реляционных баз данных, которые являются основными потребителями и создателями XML-данных".

Для того класса пользователей, которым важен контракт, основанный на проверке допустимости, получение производных типов посредством ограничения мало привлекательно, если вообще привлекательно, по сравнению с определением моделей содержания без задания ограничений. Приведенная ниже схема является эквивалентом рассмотренной выше с тем условием, что все, что от нее требуется, это гарантия того, что элемент XML-Deviant (или DareObasanjo) соответствует указанной модели данных.

Стоит заметить, что эта схема не обеспечивает отношения между типами XML-Deviant и DareObasanjo. Этот альтернативный подход неудовлетворителен для тех случаев, когда нужно поддерживать отношение подтипов.

Для сценариев использования, в которых схема применяется для создания строго типизированного XML, получение производных типов посредством ограничения чревато возникновением проблем. В реляционной модели и традиционных положениях об определении производных типов в объектно-ориентированных языках программирования отсутствует возможность накладывать ограничения на факультативные элементы и атрибуты. Приведенный выше пример, в котором элемент email является факультативным в базовом типе, а в производном не может появляться, несовместим с нотацией получения производного типа с позиции объектно-ориентированного подхода; его также трудно смоделировать, используя таблицы реляционной базы данных. Аналогично, изменение признака, указывающего, что модель содержания типа является пустой, не является характеристикой, которая соответствует реляционной или объектно-ориентированной моделям. С другой стороны, пример, в котором не используется получение производного типа посредством ограничения, более просто моделировать в виде классов на языке объектно-ориентированного программирования или в виде реляционных таблиц. Это важно, если учесть, что это уменьшает рассогласование, возникающее при попытке отобразить содержание XML-документа в реляционную базу данных или преобразовать его в экземпляр объектно-ориентированного класса.

Несмотря на то, что некоторые аспекты получения производных типов посредством ограничения плохо преобразуются, их все же можно реализовать напрямую, например, генерируя исключение при попытке обратиться к свойству или полю в производном типе, который был удален при наложении ограничения. Однако такое прямое задание ограничений XML-схемы W3C является неестественным для разработчиков, привыкших писать на объектно-ориентированных языках программирования, и маловероятно, чтобы эти правила стали общепринятыми у всех разработчиков инструментов преобразования XML-схемы W3C.