Документ примера может быть
обработан вопреки схеме, чтобы проверить какие правила, заданные в схеме
обслуживаются в примере. Обычно, такая обработка фактически выполняет две вещи,
(1) она проверяет согласованность правил, процесс называется проверкой
правильности схемы, и (2) она вводит дополнительную информацию, которой нет
непосредственно примере, такую как типы и значения по умолчанию, называемую
информационным вложением.
Автор документа примера, такого
как специфический счет на покупку, может утверждать в собственном примере, что
он соответствует правилам индивидуальной схемы. Автор делает это, используя атрибут
schemaLocation, который был обсужден выше. Но
независимо от того, присутствует ли атрибут schemaLocation, приложение свободно обработать
документ, основываясь на любой схеме.
Например, приложение, обрабатывающее покупки, может иметь установку всегда
использовать определенную схему счета на покупку, независимо от каких бы то ни
было значений schemaLocation.
Проверка соответствия может полагать
обработку в несколько шагов. Сначала проверяется, правильное ли содержание
имеет корневой элемент примера документа. Затем, каждый ли подэлемент
соответствует своему описанию в схеме, и так далее пока полный документ не
будет проверен. Обработчики обязаны сообщать, какая проверка была выполнена.
Чтобы проверить элемент на
соответствие, обработчик сначала находит объявление для элемента в схеме, и
затем проверяет соответствие атрибута targetNamespace в схеме актуальному URI пространства имен элемента. Альтернативно, он может
определить, что схема не имеет атрибута targetNamespace и элемент примера не квалифицирован пространством имен.
Допустим, пространства имен соответствуют,
тогда процессор проверяет тип элемента, либо согласно объявлению в схеме, либо атрибуту
xsi:type в
примере. Если позднее тип примера должен позволять замену на тип,
представленный в схеме, то это можно выполнить посредством атрибута block в объявлении элемента. В это то же самое время, могут быть
применены значения по умолчанию и другие дополнительные информационные наборы.
Далее, процессор проверяет
реальные атрибуты и содержание элемента, сравнивая их с атрибутами и
содержаниями, которые разрешены типом элемента. Например, рассматривая элемент shipTo,
такой как в Разделе 2.1, обработчик проверяет, что разрешено для
Address, потому что shipTo это элемент данного типа.
Если элемент простого типа,
обработчик проверяет элемент на наличие атрибутов или вложенных элементов, а
также соответствие его символьного содержания правилам простого типа. Иногда
это заключается в проверке символьной последовательности вместо регулярных
выражений или перечислений, а иногда инициируется проверка того, что символьная
последовательность представляет значение в разрешенном диапазоне.
Если элемент сложного типа, то
обработчик проверяет присутствие любых необходимых атрибутов и согласование их
значений с требованиями входящих в них простых типов. Обработчик также
проверяет наличие требуемых подэлементов и соответствие последовательности
подэлементов (и любого смешанного текста) модели содержания, объявленной для
сложного типа. Относительно подэлементов, схемы могут либо требовать строгого соответствия имени, либо разрешать замену
эквивалентным элементом, либо разрешать замену любым элементом, позволенным
посредством частицы 'any'.
Если схема не указывает соответствие
иным способом (как она может для частиц
'any'), в этом случае
проверка продолжается на следующем уровне вложения, повторяя процесс, описанный выше,
последовательно для каждого подэлемента.