В
ежеквартальном сообщении 1999 года, описание каждой объявленной части
появляется только однажды. Мы могли усилить это ограничение, используя unique, однако, мы также хотим гарантировать,
что каждый отдельный элемент, перечисленный под почтовым индексом, имеет
описание соответствующей части. Мы усиливаем ограничение, используя элементы key и keyref. Схема отчета, report.xsd, показывает, что конструкции key и keyref применяются, используя почти тот же самый синтаксис, что и unique. Ключевой элемент применяется к
значению атрибута number элементов part, которые являются дочерними элемента parts. Это объявление number как ключевого означает, что его значение
должно быть уникально и не может быть установлено в ноль (то есть всегда не
нулевое), и имя, которое связано с ключом, pNumKey, позволяет ссылаться на ключ из любого места.
Чтобы
гарантировать, что составляющие элементов имеют соответствующие им части
описания, мы говорим, что атрибут number (<field>@number</field>) этих элементов (<selector>zip/part</selector>) должен ссылаться посредством ключа pNumKey. Такое объявление number как keyref не означает, что его значение должно быть уникально, но это
означает, должен существовать pNumKey с тем
же самым значением.
По
аналогии с unique можно определить комбинации значений key и keyref. Используя тот же механизм, мы можем
выйти за пределы простого требования равенства номеров изделий и определить
комбинации значений, которые должны быть равны. Такие значения могут задавать
комбинации нескольких типов значений (string, integer, date и т.д.), для которых задание порядка и
типа ссылок элементов field является одинаковым как в определении key, так и keyref.